On to the 4th and the 5th Essential of Project Management. If you haven’t read the first 2 parts you can read it here:
Essentials of Project Management: What the don’t Teach you at Class – Part 1
Essentials of Project Management: What the don’t Teach you at Class – Part 2
4. Deadlines Are Elastic
This may sound like I am repeating the other principles. I just want to highlight it because it is easy to get boxed into a corner with aggressive deadlines. It is better to delay the delivery of the software if the programs are not fully tested and reviewed. You cannot sacrifice quality over schedule. Missing a deadline is not a crime. In fact, it happens routinely. Whether you manage this without getting overwhelmed depends on how well you have used the other principles.
The key is to recognize early when a particular schedule is going to be missed. Once you see some slippage and all means to meet the deadline have been explored, you can carefully review the deliverables and quantify the slippage. Instead of merely saying that the completion is delayed, state what will be completed by the original deadline and what will be delayed. Most of the time, the impact is not as bad as it seems at first. There are different ways to mitigate the impact: delivering in phases, overlapping acceptance testing with the construction phase, etc. Another helpful strategy is to plan for a series of small milestones within a major milestone. This will give a more positive picture of the progress and help pinpoint the problems. It also helps if you highlight potential problems early on and make contingency plans.
When you cannot avoid slippage, it is worthwhile exploring the possible ways to minimize the impact jointly with the client Project Manager. This has the added benefit of avoiding conflicts in priorities. In some situations, you will find that delays in other areas may anyway cause your schedule to slip. This obviously gets you some more time to complete your tasks. Pay close attention to external activities that have a crucial impact on your tasks such as the creation of test data. If they are delayed, you can buy some more time. Interestingly, the person responsible for these activities may also welcome the relief. I have seen cases where the client was relieved to find out that she had more time to complete the tasks assigned to her team. However, do not look at this as a way to cover up delays in the project!
If you are on top of all the tasks that are required for completing the project, regardless of who is responsible for them, you will be able to negotiate more time when needed. The important thing is, you will be able to avoid unpleasant surprises and hopefully also minimize delays. You will also be in a position to advise the client when you see that they are falling behind.
Let me reiterate one point before moving to the next principle. All the above suggestions are to be attempted only when there is no way of keeping to the original schedule. Do not count on these as easy ‘outs’.
5. Quality Conquers All
It is impossible to stress this too much. Never deliver anything that has not been thoroughly reviewed. You must include sufficient time in your schedule for walkthroughs and inspections and for re-work arising from them. Spread the reviews through the construction phase and communicate review results to the development team continually. Do not push all reviews until the end of the construction phase. That can lead to a crunch at the end in completing the reviews and the corrections.
You may wonder if you need to go through so much of review if the project is being executed by an offshore team. You may feel that the offshore Project Manager is responsible for this. You are right, he/she is. However, you are ultimately responsible for the deliverables and hence a close review is highly recommended. Apart from program code, other work products such as test plans, results, etc. should also be reviewed where appropriate. Getting an early start on this activity can save a great deal of work later on.
One thing that helps reduce quality issues is the setting of clear standards and guidelines for the programmers. Develop utilities, shell programs, and reusable code wherever possible. A project handbook that details all technical aspects can serve as a valuable aid to the team working on the project.
Finally, good luck! You will need it. But I sincerely hope that the above principles will reduce the dependence on sheer luck and make the outcome more predictable.
