The previous post around Jim Highsmith's presentation, several Agile "thought leaders," and loads of Agile Blogger's all start their conversations around the evils of "water fall" and how agile removes all those evils and replaces them with a new approach to managing projects.
Developed software is actually the outcome of agile, rather than the project management processes around developing that software. Some of the project management aspects are there in but many are of course missing.
So here's a thought. How about dropping the "red herring" of Waterfall, Full Planning, blind adherence to a Plan,Following a Process, assuming customers know what they want, assuming developers know how to build it, nothing will change, fixed schedule and cost, measures of progress by conformance to plan, valuing method more than people, resisting change, and all the other "red herrings" (read BS) that is used to divert attention from the real problem with projects.
That real problem is the failure to recognize that no matter what method you use, how you follow that method, what type of project you're working on, in what domain that project lives, there are a small number (5) principles that must be in place if you have any chance of success.
Doesn't matter if you and your partner are running a small ISV building software, or you're working on a 300 person team building software for the Space Shuttle replacement, or you're building the Olympic Village in London, or you're removing the spent fuel rods from a power reactor, you've got to adhere to these principles if you expect to be successful with your efforts.
These principles are real simple and at the same they are the core elements of any project's success. When we fail to start with these principles or fail to even start a discussion about a project with these principles, both the project and the discussion go straight into the ditch.
- Where Are We Going?
- How Do We Get There?
- Do We Have Enough Time, Resources, And Money To Get There?
- What Impediments Will We Encounter Along The Way?
- How Do We Know We Are Making Progress?
It's that simple. Don't have credible answers to these questions, you're going to be in trouble with the project. Now the answers have to be appropriate for the problem at hand. The answers have to be credible. The answers have to be stated in some meaningful unit of measure. Meaningful to the decision makers.
For each domain, context in that domain, project style, business process, maturity of the participants, technology, political space, and all the other "externalities" around managing projects - there must be appropriate answers.
By appropriate I mean answers that can be "tested" to see if they provide actionable information to the decision makers. That is can the decision maker make a decision based on that information? A decision that changes the course of the project (if that is what is needed)?
So no matter what your stripes, your "philosophy," your position in the world of project management, answers to these 5 immutable principles must be found in your favorite approach to project management and the products or services that come from that project.
WHERE ARE WE GOING?
What does DONE look like? Can we define DONE in the beginning? If not, can we define DONE before we run out of time or money? If not, then when will be able to define DONE?
DONE has to be defined at sometime. If we run out of time and money before we reach DONE, we'd probably call the project a failure.
Can we redefine DONE along the way? Sure, happens all the time. But if we redefine DONE and don't have everyone on board about the new definition of DONE, then we'd probably not call the project a success.
HOW DO WE GET THERE?
Once we know something about THERE - a description of DONE - how do we move forward toward THERE? This is called a PLAN. A Plan is a strategy for making progress. It is not a Schedule, it is not a list of work, it is not a bunch of sticky notes on the wall.
A Plan - shows in ways that can be understood by all the participants - the steps to be taken to reach DONE. The Plan shows the dependencies between these steps. What "chunks" of the deliverables has to come first. What things have to be in place before other things can be built on top of them. This are sometimes confused with priorities, arrangements of dependencies are not the same as prioritizing the user stories.
The Plan can be changed of course, just like your Plan to reach the airport on time to make your flight. Or the Plan to reach the top of the mountain. Or the Plan to graduate from college in 4 years.
Plans change. Anyone thinking Plans don't change isn't a very good planner.
DO WE HAVE ENOUGH TIME, MONEY, AND RESOURCES TO GET THERE?
When you're spending other peoples time and money, you should have an answer for this. If you think you can give some lame answer to the question "how long is this going to take," or "how much will this cost," you're probably not spending someone else's money.
WHAT IMPEDIMENTS WILL WE ENCOUNTER ALONG THE WAY?
These are called Risks. And "Risk Management is how Adults manage projects." That's what Tim Lister says.
No risk management plan, low probability of success. But risk management is more than mouthing the phrase "our method reduces risk." That statement needs to have quantifiable measures of performance. That performance is risk reduction measured in reduced defects, reduced rework, reduced cost for the same compliant outcomes. These measures need to be statistcally sound, "Beyond the Hype" is a good book speaking to the problems of modern process improvement "hype" in the absence of numbers.
HOW DO WE MEASURE PROGRESS?
It's progress to Plan by the way. Measuring progress in the absence of a Plan for that progress is real easy. The consumption of time and money is a measure of progress.
But saying what you plan to do, then measuring if you did what you said you were going to do, that's harder.
Here's a real simple measure of progress. Did the thing you said you were going to do, actually show up at the time you said it was going to show up, for the money you said it was going to cost, and did it actually do what you said it was going to do? All this of course adjusted for the variances in the plan?
Was the outcome of you efforts within the error bands of the natural variance of your plan?
No? Then you didn't do what you said you were going to do. You're late and probably over budget as well.
