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.
- DSDM tells us to create a Feasibility Study (check if the project is worth doing) and an Outline Plan (set some high-level project parameters).
- MSF tells us to create a Vision/Scope Document (to define project direction and boundaries) and a Project Structure Document (team, process and budget).
- Prince2 names the Business Case (the customer's reason for doing the project) and the Project Plan (schedule, milestones) as the two most important documents in this phase.
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:
Business Case
The Business Case is the chapter that defines why the project is needed.
- Current Situation
To understand the project, every participant needs to understand how things are working now. - Problem
Make it clear to everyone that you really understand why the project is needed, and what the problem is in the current situation. - Vision
All stakeholders in the project need to be aligned so that they share the same vision of the future product. - Options
Document why a certain direction was chosen, and from which available options. - Benefits
Make sure that everyone has the same idea of business value for the customer.
Project Scope
The Project Scope is the chapter that defines what the project will produce.
- Scope
Define, in broad terms, the size of the project by explaining what activities you will perform, and for how long. - Out of Scope
It's also very important to mention explicitly what you will not do, so that there will be no misunderstandings. - Solution
Give the customer an idea of the (sub)systems you will be delivering, without details, on the highest possible level. - People and Roles
Name the stakeholders and their roles and responsibilities in the project. Make sure that everyone knows who can take which decisions. - Quality Criteria
Name any quality requirements that are applicable, and assign priorities in case of conflicts among the qualities (like performance vs. security). - Standards
Name any technological standards and business standards applicable to the product. - Risks
Be sure to mention any risks, so that any re-planning (when some of the risks turn into real problems) doesn't come as a surprise later.
Project Planning
The Project Planning is the chapter that defines how/when we intend to do the project.
- Process
Mention the process you will apply, either by referring to a defined method (like Scrum) or to a document describing your own custom process. - Milestones
Name any specific dates and (if known at this stage) what you expect to be delivering. Regular iterations/releases might be mentioned here. - Dependencies
Name any dependencies, like the involvement of third parties, that are beyond your own direct control. - Assumptions
Make any assumptions explicit, like the availability of a customer stakeholder, or the availability of graphic designs. - Change Management
Define how you're going to cope with changes during the project. This is part of the defined process, but it deserves to be mentioned explicitly.
That's it!
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:
- Don't include the budget in this document. Reserve that for a separate (small) contract or proposal. The customer might want to share your stunningly insightful document with other stakeholders inside his organization, but he might be reluctant to share contract and pricing details with his own subordinates.
- Use the same template for your own internal projects. You might be your own customer, but that doesn't mean you don't have to answer these questions to yourself.
- Present the document during the kick-off meeting with the team, and let them ask questions to fill any holes and blind spots in the written document. The agile principle of verbal communication should be able to take it from there, and your standard development processes can finally take over.
Want to read some more?
Why Managing Small Projects is Harder
