As I said before, I have not yet made up my mind about the CMMI…
How Do You Initiate a Project?
Do you just organize a kick-off meeting? With a friendly pat on the back by the customer, wishing your developers all the best? I'm sure you don't. The agile principle of verbal communication over written documentation is applicable when a project has already started. But before that, when a contract still needs to be signed, and when the customer is still reluctant to trust your shiny blue eyes, at least something has to be written down and agreed upon.
Let's call this the Pre-Project Phase. It's the only phase where you're not sure if it will be followed up by anything else.
The Project Proposal
Until this day we have initiated projects in our company by writing Project Proposal documents for our customers. Such a Project Proposal usually contains an outline of the project, a vision of the intended solution, the planned phases, milestones and deliverables, the budget, pricing details, a description of our agile processes, licensing and maintenance stuff, and promo's for other products and services. And every now and then some business unit manager adds another standard paragraph to this ever-expanding nightmare of a document template. Our Project Proposals have become so big that some of our customers complained of risking a repetitive strain injury just by leafing through them.
Something had to be done!
Software Development Methods to the Rescue
So, I checked a number of books and methods to see what the common approaches are to documentation in the pre-project phase. These are the results:
Well, isn't that a pity. The best-known agile methods leave the initiation of a project completely up to your own imagination. Fortunately, there are several more methods to choose from, and I quickly found some useful advice.
There is a significant overlap of subjects addressed in the different documents suggested by these methods. As a person who likes to keep things simple, I decided to create just one new document template for our organization, aggregating the most important topics I could find in several document templates. Here is the outline of my new Pre-Project Document template:
The Business Case is the chapter that defines why the project is needed.
The Project Scope is the chapter that defines what the project will produce.
The Project Planning is the chapter that defines how/when we intend to do the project.
This outline is simply the result of me stealing generously from various examples in DSDM, MSF and Prince2, and wrapping up all topics into one simple document. Hell, I even matched the outline with the objectives of the RUP Inception Phase, and everything appears to be neatly covered. Now, it doesn't really matter whether you call this document a Project Plan, an Outline, a Project Vision or a Pre-Project Feasibility/Scope Plan Outline Document. Just make sure that your ass is covered and all this stuff is agreed upon with your customer before doing that first daily standup with your team. Because, after the project is started, your Pre-Project Document will be the basis against which your project, and the resulting product, will be measured by the customer.
Finally, a couple of tips:
Want to read some more?
Why Managing Small Projects is Harder