When preparing to embark on a new project it is useful to establish a proper expectation on cost, time, and quality of the project. So here are a few things that you should think about and document as part of your planning process,
- Project scope statement: What exactly will the project accomplish?
- Project management plan: How will the project be monitored? Will a single person keep track of the hours and scheduling? How will the customer, or stake-holders, be kept informed of how the project is proceeding?
- Work breakdown structure: The chunks necessary to complete the tasks assigned in the scope. This may be Trac tickets, or code modules, etc..
- Resource allocation: Who will be on the project and when?
- Risk analysis: What are the most likely things to go wrong? Often it’s that the code takes longer to write than expected, but what about unexpected hardware problems, time constraints, or specific customer issues?
When doing your analysis, it’s easy to see the big picture. However, there’s a lot of small and not-so-small tasks that you need to remember. There’s a good chance you’ll need to take into account the following tasks, even if individual task sizes will vary based on the size of the development team and the scope of the application.
Status meetings, phone calls, talking to customers, managing people, generating reports, mid-stream application redesigns all add up to a big chunk of change. Some projects can get by with 10% overhead, others will push 50%. It depends on the size of the project and the degree of reporting desired. On some projects I was able to get the overhead down to about 8-10 hours for every 120 hours logged. But the numbers went up markedly at the start and the end of the project life-cycle.
Time to estimate the project task estimates
Since Enthought is a software company, we estimate how long it will take to write or provide a software application. Estimating how long it will take to write code is one of the riskiest estimates in a project since ongoing development often reveals additional features or hurdles that were not originally planned for. Creating the task estimates requires having some of the design work completed to make sure all subtasks have been identified. Therefore, the risk of estimate overruns can be reduced by doing a design phase to identify, design, and estimate the subtasks. But extensive design phases can be expensive and possibly wasteful if the project scope is changed to not include the estimated subtasks.
Software build deliverable
Generating a build of the application for the customer should be a trivial task but historically all kinds of problems crop up with libraries, paths, versioning, you name it. Make sure to plan enough time to deliver to the customer the product or service they requested.
Team member training
There will need to be an initial training phase for any new team members joining the project. If the team is already trained then the estimates can be low, but if there is a lot of new domain knowledge to be learned, or the initial development environment takes a long time to set up, or there will be a lot of members joining and leaving the team then this number could be much higher.
Demos and project realignment
In a dynamic and iterative development environment like we have at Enthought, the customers play an active role in the guidance of the tools we write. That means we take time to demo the application, and integrate the feedback they provide into what has already been written and where the project is going. The demos and realignments take time, so include them into your schedule and budget. One possible time-sink is rewriting GUIs that already work, but need to be redesigned based upon customer feedback.
Integration testing is different than unit tests, in that problems can arise when pieces start fitting together. Integration can mean different things for specific projects. For example, integration testing might verify that Envisage Plugins that were written separately do actually work together, or it could be testing that the application integrates with the customer’s target server, or it could be integrating an old code base into an new environment.
Before delivering the final product it should be rigorously tested to verify that everything works as expected. New features may have accidentally broken something that was tested in the past, so the application should be locked-down and tested one last time before being sent out.
Documentation is an important component of a project, yet often forgotten by developers when doing a work breakdown analysis. When estimating documentation costs, be sure to include the time that the technical writer will spend on writing the documentation, AND the time that developers will spend being interviewed by the documentation team.
A time reserve, or ”contingency allowance” should also be created. This pool of resources is then managed by the project manager to be used as needed. Unexpected events occur in projects with such regularity that they often are included in the initial estimates and called ”known unknowns” so that other task estimates can be exceeded without a need to modify the project schedule. Some developers calculate a value by multiplying the total estimates by a scaling factor, but the multiplier is only useful if the original estimates are correct. Whether the reserve resources are actually included in the budget plan depends upon who the estimator is. A developer shouldn’t be able to dip into the contingency allowance without the project manager’s approval. But then the Management Team may have a second contingency allowance for ”unknown unknowns” that even the project manager does not have access to without approval.
When doing your analysis, the big pictuce