By Cary Toor
For all software development projects, we start with a project plan divided into milestones and tasks. To get the project done, we need to know the status of each task and mark the task as done when it is completed. Is it done yet? Can I mark it as complete? These are the critical questions in project management.
In the days when I managed or oversaw projects, I felt like a broken record because I asked this question all the time (and everyone in my organization was tired of hearing it). I am sure that everyone who has managed software development projects feels the same way (at least most of the time).
You would think that this would be an easy question to answer (since it is a simple yes or no answer). Unfortunately, this simple question is where project schedules and budgets tend to fall apart.
In this short discussion, I will attempt to provide some tools and techniques to get an accurate answer to the question, “Is it done yet?”
First, what does done (or 100% complete) mean? It means that the coding task is done, that the developer unit tested the task, and, hopefully, that a tester has followed up with his or her own unit testing and signed off that the task meets the requirements. It does not mean that the coding is done and testing is pending or that testing is in progress. Done means done!
Now, let’s look at how this works into a real project. Project plans (schedules and budgets) are creating by devolving the project functionality or if you are using Agile, the functionality assigned to the construction iteration, into a series of subsystems, modules, and coding tasks; progressively smaller chunks of work that are finite and easy to understand. If we strive to make the coding tasks small with clearly defined functionality (say no more than two-to-four days of effort), it is not difficult for an experienced developer or analyst to quickly build a working project plan with reasonable effort estimates. Unfortunately, every Project Manager knows that good project plans only stay on track a small percentage of the time (which is why getting a project done on schedule and budget seems to be an elusive goal).
So why is this? Let’s assume that your requirements are correct (a very large assumption) and talk only about the coding or construction phase. So, is the task done? A strong, experienced developer who has unit tested his code says “yes.” What could possibly go wrong …
- the code could blow up when certain functionality is exercised.
- the code could have subtle logic errors.
- the code may not integrate correctly code written by other developers.
- the data model may have been changed.
- the code may work in the development environment but not in the production environment.
- …and so on.
As I indicated above, assuming that you have experience with software development, in theory it is easy to estimate how long a small, well defined coding task should take. What is impossible to estimate is how many iterations of testing, followed by bug fixing, followed by retesting will be required for any given piece of code. This can be dependent upon …
- the individual developer assigned to the task.
- the quality of the tester assigned to the task.
- the quality of the development environment.
- …and so on.
Compounding this, the longer it takes to uncover the problem, the longer it takes to get that problem resolved. If the problem is uncovered during initial development or immediately thereafter, the developer can usually correct it quickly. If the problem is not uncovered until later, the developer has moved on and is working another task. That means (a) the developer has to stop working on the task he or she is working on, pick up the prior task, attempt to figure out what he or she did previously, and resolve the issue, or (b) the testing has to stop and wait until the developer is done with his current task. For obvious reasons, both of these are bad options with an impact on the project budget and schedule. A few tasks with simple fixes might not create any scheduling impact (because of course we all pad our schedules). Multiple this by 50 or 100 tasks and the schedule goes downhill quickly. Option (b) is probably the best option. Early in the project, the tester can move onto other sections of the project, although this is how tasks get marked 80% or 90% and never get completed. Option (a) is the only option as the project proceeds into its later stages to make sure tasks actually gets to 100% complete.
So, what can you do about this? Of course you could pad every coding task in the schedule by 50% – 100% or you could greatly increase the time and resources scheduled for testing. Whether you can get away with this depends on how flexible (read malleable or lack of concern) your customer and other stakeholders are about the project schedule and budget. Alternatively, here are some strategies you might use to reduce this problem …
- When you are creating the project plan –
- Make sure the tasks are small enough to accurately estimate (such as a single simple Web Page, Tab on a Page, or Stored Procedure). It gets very difficult to close out a task if it requires more than 1-2 days of coding effort. Also, remember that it is easier to code and test a single, simple piece of functionality that a complex piece of functionality by a factor of many times. (This is why tasks should be small!)
- If you are using code-driven unit test tools or frameworks, schedule in ample time to write the unit tests for each task so they are robust and likely to identify reasonable coding errors.
- Move up the initial integration testing of each major component of code (i.e. anything that can be tested stand-alone) so that it is done immediately after all coding tasks are complete. Do not defer integration testing until all coding is complete.
- Overall during the development / testing tasks –
- Have a tester unit test the code independently (or view the developers unit testing) immediately after the coding is complete.
- Have the developer fix any problems identified before they move on with the next task (where possible).
- On the developer side –
- Developers do not like to do thorough unit testing. Make sure your developer is actually doing the unit testing (and not handing off buggy code).
- For each developer, track the iterations required to close each module (this functionality should be available in any reasonably robust problem management tool). It turns out that developers are pretty consistent; either high or low. There is no grey area. If the iterations are consistently high and you point this out, it can get substantially better.
- Have the developer sit with the tester at least some of the time or involve the developer in group testing activities in which the whole team comes together to do testing of the entire project.
Developers usually have a style; (a) slower coding, lower bug counts, (b) faster coding (30%-40% faster), higher bug counts. One of my Project Managers was always stressing to me that the slower coding, lower bug count developers are better (or at least more predictable)!
In any case, done needs to mean DONE. It can’t mean half done, 90% done, or done without independent verification. Projects are not completed when 100% of the task are 90% done. Projects are only complete when 100% of the tasks are 100% done. I know this is obvious, but I have seen many projects where 50% of the tasks were marked 70%-90% done and the stakeholders are screaming about the budget and schedule getting broken. The bottom line… Don’t mark a task as done until you have some independent confirmation that it is done!