Vin, has a post that outlines sources problems for project failure. I read this that each topic is the source of the project's problem. And then there is the suggestion that Agile can "fix" these problems. Like many suggestions around agile, there needs to be a seperation between "bad program management," actual benefical outcomes of agile, and the measureable outcomes from applying agile to specific problem domain and context in that domain.
- Requirements: (there are) Unclear (requirements), (they) lack of agreement, lack of priority, contradictory, ambiguous, imprecise.
- Resources: (there is a) Lack of resources, resource conflicts, turnover of key resources, poor planning.
- Schedules: (are) Too tight, unrealistic, overly optimistic.
- Planning: (is) Based on insufficient data, missing items, insufficient details, poor estimates.
- Risks: (are) Unidentified or assumed, not managed.
Each of these can be traced to much simpler source than just the red herring of WaterFall.It is suggested Agile can address these issues. So let's look at that conjecture a bit more.
Requirements
A Requirement is ... "A statement identifying a capability, a physical characteristic, or a quality factor that bounds a product or process need for which a solution will be pursued." - IEEE Standard 1220-2005.
Along with requirements successful projects need to define what capabilities are to be provided by the solution.
A Capability is ...“the result of a method involves a functional analysis of operational requirements. Capabilities are identified based on the tasks required… Once the required capability inventory is defined, the most cost effective and efficient options to satisfy the requirements are sought.”
So when it is said "forget requirements, tell stories instead," what does this really mean? Because a story is a requirement. A requiremment told trough the narrative of the stiry. But it's missing several things good requirements need:
- Traceability of the Requirements to the Business (or mission) Capabilities. Why is this requirement here? What other requirements are related to this requirement? What are the dependencies between this requirement and other requirements? If I drop this requirement to hold the iteration completion time, what's the impact on other requirement in the release.
- Requirements can be represented in many ways. Scenarios are common in our domain. sysML process flows, systems engineering Concept of Operations, and other "story like" narratives can be found in defense
Resources
Resource management is a critical success factor for any project. The estimating, acquisition, management, and forecasting resource demand is the role of program management. The notion that Waterfall is somehow the source of the problem is a big stretch. Bad Project Management will ignore the resource management role. Resource Management is Chapter 9 in PMBOK and other chapter in other PM guides. This is NOT a waterfall isseu, it can just as easily be an agile issue too if not looked after.
Bring in resources as needed including using temporary workers to cover peak demand.
Really, how many resources, what kinds of resources, skills, capabilities, cost, fit with team?How far ahead do we need to start recruiting these resources? Our HR department has 3 full time recruiters just scrambling everyday for PM's, Program Managers, PP&C staff, testing, cost, and all other skill sets needed on our programs.
Agile provides no unique solution here.
Schedules
If your schedule is overly optimistic, then you've got a bad schedule. Period. You're a bad project manager if you sign up for this schedule. You've violated your obligation as a PM for provide a credible probability of success. You've probably violated the ethics code of your PMP.
Either allow schedules to flex or fix them and allow features to flex. You can’t have it all.
Here's some advice we apply and provide to our clients:
- A schedule without margin is late and over budget before you start.
- How much margin needs to be determined analytically. Either through past performance analysis on one end and Monte Carlo Simulation on the other. Either way, or all ways in between mean that you have some understanding of the probabilistic nature of the durations, cost, and technical performance.
- Schedule have show the order of development at some level to maximize the value stream to the customer. This is done on multi-billion weapons systems and done in agile projects.
Planning
A Plan is a Strategy for the successful completion of the project. It's the Plan that describes the sequence of activities needed to maximize this value. Be the value autonomous landing of an F-18 on the deck of a carrier, the delivery of telecommunications services to clients, or some type business capability to customer. The notion of exchanging planning for deliverables requires very careful consideration. With a credible Plan, you cannot know what to deliver. A pile of story cards stuck to the wall is not a plan. It's a pile of story card stuck to the wall.
Plan less, deliver more. Let the deliverables guide the planning.
Which deliverables? What order are needed to minimize the duration of the project? What are the dependencies between these deliverables? Are there deliverables that depend on other deliverables? Who decides what order the deliverables appear? Is there oversight around these deliverables, their connection with the Capabilities needed for business success.
This has nothing to do with Waterfall and is not solved by Agile. Here's a sample of a Plan used for a Scrum based very large insurance program.
Risk Management
Let's start with the seminal quote:
Risk Management is how adults manage projects - Tim Lister
Vin suggests
Evaluate, prioritize and mitigate risks on every project.
Well close, here's some guidance
But the process actually is:
