Whenever we are running an IT project, if we already have a deadline set before the start, no matter what, this project will turn into more a cascade than an agile conduction. Besides this status report, I’m listing the minimum artifacts to have a successful project being delivered.
The scope is basic. It is the base for everything to come. You will extract everything from the scope: the schedule itself, the pace you have to go to keep the schedule, and the team to reach everything. The key information that must be in scope are:
- The requirement list;
- The details of each requirement;
- For who is that requirement applicable?
- Who has validated the details?
- The time estimates to reach that deliverable;
- Who is needed to perform the technical part (strong dependencies only);
You don’t have to hold the fanciest document. You just have to hold a document that everybody involved can understand. I’m suggesting this document model.
As soon as you have the scope, you will be able to start taking operational decisions. What are the restrictions you have for your schedule? What team is enough for you to reach the given deadline? Can you beat it earlier than planned? Always plan to finish the project before your schedule says, and keep some margin for the problems to come.
The key information that must be in your schedule is:
- When will you deliver each requirement;
That’s enough. I strongly disagree with going anywhere beyond this point. Otherwise, the project manager will dive to an endless cycle of micro controlling everything. Issues will come with simple or complex documents. Go ahead and create your own model. List the requirement and the date to be delivered;
The status reports
The status report is a weapon and should be used wisely. It can be used to mark milestones for the project and also to create a sense of urgency for some scenarios. It is a powerful weapon. Do not avoid using it. Here you can find the model I’ve been evolving for years. Some of the key inputs:
- What changed from last status report to this new one?
- Who are the responsible people for taking decisions on this project? At least one on the delivery team and other on the client (internal or external) team;
- Where are we in the schedule? Do use percentage here.
- Major executive items (green/yellow/red) like scope, people and schedule;
Still in the status report. Always remember: if people are asking you for a status report, it means a huge problem. Not sending or wanting it, but the act of asking for it. If they ask for an email to get to know how the project is going on, it automatically means they are not involved as should be on the project. If the status report is green, everybody knows it. Or if the status report will have bad news, everybody must already be feeling the bad news.
The scope changes
Since you are running a cascade project, be prepared for scope changes. I haven’t seen a single project where they didn’t happen. When I hear a scope change, I know I’m walking the wrong way. But it makes me happy because I’ll have the opportunity to put things back on track before the end of the project. Keep track of all scope change requests coming from all the team involved. Make it very clear those already approved and those which won’t be pursued for any given reason. A scope change track document will have the following information:
- The new requirement OR requirement changed;
- The description of what’s changed;
- What’s its impact over the schedule;
- Is it included in the project or not?
Few other activities will require you to have a kind of formalization. Using email for that is enough. Some of them will be:
- Deliveries approval;
- Changes approval on scope and schedule;