Categories
- Agile (6)
- Architecture (1)
- art (2)
- Big Data (1)
- books (11)
- Cars (1)
- Change (9)
- common sense (3)
- Contracting (1)
- Cool (1)
- Design (5)
- development (1)
- emotions (3)
- entrepreneurship (2)
- google (1)
- great quotes (2)
- happiness (1)
- innovation (3)
- IT (8)
- IT Architecture (3)
- Knowledge Transfer (2)
- leadership (3)
- Lean (1)
- links (1)
- literature (1)
- lyrics (1)
- management (9)
- Media (1)
- Negotiating (1)
- networks (1)
- people (5)
- Personal Improvement (8)
- planning (5)
- productivity (3)
- Programming (1)
- Project Management (23)
- Projects (1)
- psychology (3)
- Requirements (5)
- Risk (2)
- scrum (2)
- strategy (6)
- struggle (1)
- summer (1)
- teams (5)
- Test Automation (3)
- thinking (5)
- Training (2)
- Travel (1)
- waterfall (4)
Tag Cloud
Agile
Architecture
art
Big Data
books
Cars
Change
common sense
Contracting
Cool
Design
development
emotions
entrepreneurship
google
great quotes
happiness
innovation
IT
IT Architecture
Knowledge Transfer
leadership
Lean
links
management
Media
Negotiating
people
Personal Improvement
planning
productivity
Programming
Project Management
Projects
psychology
Requirements
Risk
scrum
strategy
teams
Test Automation
thinking
Training
Travel
waterfall
Early Planning Pain
Posted by Rich Crowley in Project Management
One of the big struggles in the life of a PM is meeting the demand for a full project plan prior early in the project. Business management needs the ability to plan and so their request is not unreasonable. However, it is often very difficult to come up with a plan that has detailed task breakdowns, resourcing, estimates and so forth for tasks in the project that are beyond the initial phases / iterations with any level of confidence.
You can put a high level plan in place for those tasks beyond those in the near term but you often need to put some buffer into these in order to account for a wide range of unknowns (resourcing challenges, slippage in nearer-term deliverables, lack of clarity around what tasks are needed, exactly what skills are needed, dependencies on other projects, etc. The problem with doing this is that such a number will often be large and is not easily defended, which frustrates the business user looking for more certainty.
What to do? There are a number of approaches to tackling this problem. One approach is to have a planning session very early in the project with the relevant business managers involved (ie. sponsor, key stakeholders, etc.) and during that meeting attempt to develop an estimate of the work and a timeline together. If the project is reasonably simple, this may produce great results. If it is complex, you may be no closer to meaningful estimates and/or a schedule at the end of the meeting than when you started but at least your business stakeholders will have a first hand understanding of why.