The calm before the storm

There’s a certain calm that you experience when something is going to go inevitably wrong. The animals are silent, there’s no air waving, people stay inside their houses and the environment feels obscure and heavy. Some people say that this is the calm before the storm, before everything and everyone is violently threatened, and you need to put into test all the surviving skills that you learned in this blog. But, you still have time to prepare and grab any tool or resources that you might’ve forgotten. These are the final preparations.

Storm by Adam Singer

Creating Project Estimates

After the quality and change boards are set, the preliminary planning has been done, the requirements have been stablished and the architecture designed, it’s time to start taking a guess on how much time, money and staff is going to be needed to achieve the project at hand. You need to have a good estimate in order to ask sufficient resources and the books suggests a series of rules of thumb to take into consideration while estimating.

• It’s possible to estimate software projects accurately so stay calm.
• Accurate estimates take time.
• Accurate estimates take a quantitative approach, preferably one supported by a software estimation tool.
• The most accurate estimates are based on data from projects completed by the same company that’s making this project
• Estimates require refinement as the project progresses.

Keep this rules as mantras because the estimation process could be a stressful one in certain steps are not taken into consideration, but good guy McConnell gives us a guideline so that we don’t stress ourselves to much. He says the following:

• The estimation procedure should be written.
• Estimation should include time for all normal activities (even sick days).
• The project plan should not assume the team will work overtime.
• Estimates should be created using estimation software.
• Estimates should be based on data from completed projects.
• Watch for estimates that developers don’t accept.
• The project team should plan to reestimate at several specific times during the project.
• Estimates should be placed under change control.

After taken into considerations the guidelines above, it’s time to set start dividing the project into deliverable milestones, so that everyone understands when and what should be expected to track the progress. The biggest milestones of this approach that need to be written down are the following:

• Architecture (Complete)
• Stage 1 complete
• Stage 2 complete
• Stage 3 complete
• Software release (assuming only three stages)

As we can observe, the estimation process is much complex that we might thought it was. Also, keep in mind that many parties will be affected by these estimations so be sure that all the stakeholder agree with the estimations given. You don’t want developers rebelling themselves or everyone quitting the company because you make them work overtime through most of the project because your estimations where wrong and you didn’t want to reestimate.

Writing a Staged Delivery Plan

The biggest milestones have been set, but stage 1 complete sound a bit too shallow. We need to be a little more specific, and for that, as always, planning is required. Under the process of this book we need to remember that the most important functionality is delivered first so that the user’s needs are met quick. The sooner the better, right? The first stage deliverable should take this into consideration and the rest of the stages should be designed under this concept and aggregate more functionalities on top of the first run. Thus, planning by stages needs detailed technical planning, careful management, and solid architecture.

An effective way of diving the deliverables by stages are dividing the project into themes. The approach that needs to be taken is to have in mind that it should be divided from most important functionalities first to the least at last. An example from the book of how a division looks like is the following:

As you can see, the sooner you can show the client that the needs are being met, the better. Of course, it’s not necessary to show the client the status of the project each stage. It’s better to have something more robust to show that just some lines of code or a useless interface. Unless your client ask to you should keep the meetings the further the better.

At the end, the stage delivery plan is just as any other document that we’ve been talking about. Make sure that it goes under change control, but also remember that this specific document will be on constant update. So, treat it as something that will be revisited many time.

Performing ongoing planning activities

The final preparation stage is also a time of checking if everything is still in good conditions, so we need to step back and revisit some of the previous activities that were stated during the preliminary planning, for example:

• Risk Management: As project tasks become better defined, so do risks. Be sure to update the top ten risk list to reflect what are the new risks that were encountered.
• Project Vision: Through careful planning, design and documentation the project starts becoming something more tangible and less conceptual. Many thing have been learnt and they need to be incorporated into the project vision.
• Decision Making Authority: It’s time to have all the issues and concerns put in the table again and make sure that the decision-making authority that was designated during the preliminary planning knows the changes and decisions that had been made since the first talk.
• Personnel: before starting the trip let’s check the wheels of our car, or the gears of our clock in this case. Is the morale up? Is there someone problematic in the team? Does everyone in the team feel comfortable with the challenge ahead? This is an appropriate time to assure that the team’s health is good state.
• Software Development Plan: The software delivery plan should be updated and revised as many things have been learn and modify since the first time it was created.

The tools have been checked, new provisions have been bought, and need that we didn’t know we had have been found. Can we be better prepared for the challenge that lies ahead of us? Maybe, maybe not. Experience will teach us over time, but right now it’s time to have a high morale and to have always in mind that we will survive the storm and return home triumphant.

References

McConnell, S. (2014). Software project survival guide. Redmond: Microsoft Press.