-
When Reality Hits - Project Managers Roll With It
February 11, 2012
-
When IT Is Your Company’s “Piggy Bank”
February 10, 2012
-
4 Key Things a Project Manager Must Do
February 10, 2012
-
Essential Project Management
February 10, 2012
-
8 Traits of Top Project Managers - Part 1
February 9, 2012
-
Agile Project Management - Engaging Your Customer!
February 9, 2012
-
9 Tips to Avoid Traps in Project Planning
February 9, 2012
-
Why Projects Succeed - Executive Sponsorship
February 8, 2012
-
On Customer Participation in Agile Projects
February 8, 2012
-
A Project Charter for Lazy Teams
February 8, 2012
Agile Project Management & Product Strategy - A Case Study - The Original Product Development Plan
October 13, 2008 | Author: PM Hut | Filed under: Agile Project Management
Agile Project Management & Product Strategy - A Case Study - The Original Product Development Plan (#2 in the series Agile Project Management and Product Strategy - A Case Study)
By Eric D. Brown
On my first day with the company, I walked into the office and found myself staring at a very large Gantt chart hanging on a wall. The chart had the words “Product Development Roadmap” written across the top and looked just like every other Gantt chart ever created (e.g., milestones, resources, dates, timelines, critical path outlines, etc etc). My first thought was that least they understood what they were trying to do and had a plan. My second thought was ‘what are they delivering and when are they delivering it?’
I sat down with the team and over the next few days and discussed the product development strategy. I realized that the original development plan created with zero lead time (each task could only start when the previous task finishes). My gut feeling told me that his was done to lengthen the project and create more billable hours for the previous consulting company.
Since the plan was created using zero lead times, it required that all network architecture design had to be completed before any database design could be started. In addition, all database design had to finish before any work on the User Interface could be started. The same holds true for documentation and testing.
As you can see from the high-level overview of the plan shown in Table 1, it would have taken 9 months before a product was available to demo and/or beta release to a client and 12 months for a final release.
| Task | Timeline |
| Network Architecture | 60 Days |
| Database Design | 60 days |
| Content Management System Integration | 60 days |
| User Interface | 120 days |
| Demo to Clients | 9 months from start of project |
| Documentation | 30 days |
| Testing | 30 days |
| Total | 11 to 12 months from start of project |
After reviewing the plan and talking with the leadership of the company, I started looking at methods to “bring the plan in” so we could provide a demo and beta release much sooner than 9 to 12 months out.
The original resource schedule for the development provided for 1 network architect, 1 database architect, 1 user interface ‘guru’, a documentation specialist and 2 QA specialist’s.
About Eric D. Brown:
Eric is a consultant specializing in IT Strategy, Selection and Implementation with over 14 years of experience in project leadership roles. Eric’s blog, found at http://ericbrown.com, provides an insight into the struggle of trying to align technology, strategy, people and projects.
Related Articles
feel free to leave a comment
Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!
XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
All fields marked with " * " are required.
- Agile Project Management
- Ask the Hut
- Certification
- Change Management
- Communications Management
- Computer Based Information Systems
- Concepts
- Corporate Transformation
- Cost Management
- Critical Chain Project Management
- Delegation
- History
- HR Management
- Implementing Project Management
- Integration Management
- Lessons Learned
- Management
- Miscellaneous
- People Issues
- PMBOK
- PRINCE2
- Procurement Management
- Program Management
- Project Lifecycle Phases
- Project Management Advantages
- Project Management Advantages
- Project Management as a Career
- Project Management Best Practices
- Project Management Charts
- Project Management Definitions
- Project Management Ethics
- Project Management for Beginners
- Project Management Guides
- Project Management Musings
- Project Management Office
- Project Management Proposals
- Project Management Templates
- Project Portfolio Management
- Project Workforce Management
- Quality Management
- Requirements Management
- Risk Management
- Scheduling
- Scope Management
- SCRUM
- Soft Management
- Time Management
- Training
- Uncategorized
2 people have left comments
Eric, I want to thank you for a great post on one of the more prevalent reasons why timelines escape people. I’m not sure about your experience in this post exactly, however, the client (in those cases where a consultant has been retained) is often driving a poor timeline. It’s difficult to discern when one comes in later to clean up. It sounds a lot like that’s what you were doing in this scenario. I want to agree with you whole-heartedly and add that consultants and analysts have to push back on clients/customers when their timing is unrealistic. It may upset them initially but in the long run it’s far better to manage expectations that are ultimately possible.
Thanks much
Patrick
http://www.workflowiq.wordpress.com
Hi Patrick,
Thanks for the comment. You are exactly correct…I was brought in to “clean things up’ and you’ll see in subsequent posts that clean-up is exactly what we did.