Bring in a super developer; bring in an expert, a guru and a genie...!
If you have worked on any software development, projects, you know you're looking for that project to be delivered within its estimate and on time.
If you are a project manager in software development, odds are that at any given time you're managing multiple software development projects (at various stages) and each stakeholder is looking for their projects to be within the estimate and to hit the expected deadlines.
How can you achieve this repetitively?
We've been working on software development projects for a while now, and I've tried various project management methodologies, a range of requirement documents, technical designs, unit tests, test plans, post project reviews...all of which helped greatly, but the estimates I received for a project were nowhere near accurate enough.
The project that should be finished by now, has been 'almost there' for a month, or that project that was meant to take 100 hours to develop and 120 hours later your latest information says the project has at least another 50 hours to go. How did you end up here, is that 50 hour estimate believable and why does this happen so often?
What often gets overlooked in the rush to get projects completed on time is implementing a reliable method to help your team repeatedly perform. Transform from a scenario where some developers tend to be better at meeting estimates (regardless of experience) to a team being able to estimate on all projects with an accuracy that is repetitive.
I have two ingredients for you: peer reviews and small estimates. If you haven't heard of these before, here's how they can help you and your team.
Simply put, every technical design and every line of code is reviewed by another developer. That might sound like a big overhead, but it's an investment that more than pays for itself. Every time another software developer reads someone else's code and it doesn't look like a quality solution or if it's something new, one of two things may happen.
- The reviewee either learns something about code standards, how to solve a puzzle or a better method of achieving results.
- The reviewer can equally learn something, and maybe merge their knowledge to create solutions which are better than either indiviual could come up with.
When this happens, the project and the proceeding projects will quickly become of higher quality and will also be more likely to meet the project needs on time.
The more ofter peer reviews happen, then the quicker those peer reviews are completes. This is because your team gets better at communicating and working together and they are also more likely to prouduce quality code first time round. Reducing the time it takes to complete a development project, reducing the time it takes to test and debug software and, most importantly, reducing the risk of something going wrong or the unexpected coming up.
How? I suggest:
- Split work into work packages with a technical 'owner' and a 'reviewer'.
- The owner is responsible for writing the technical designs and the code.
- The reviewer is responsible for reviewing the technical design (ensuring that the designs are quality and that they meet all the requirements) and reviewing the code (checking that the code is well written, meets code standards, is maintainable, and has no obvious issues).
- Reviews happen regularly, at least once a week, so that the information is relevant to what the technical 'owner' is working on.
Many people estimate based on how well they believe they understand a task. The more uncertain they are about the task, the bigger the estimate becomes. The more they understand what needs to be done, the smaller the estimate. There is disjoint here in that they have not really thought through how long that task will take, but produce an estimate based on their own confidence. Your project estimators need a solid background in how to produce an accurate estimate.
The standard method for producing better estimates is to look at the project after the fact, or when it becomes obvious that things are not running to the plan - at which point it's too late. Adopting 'lessons learned' can also be difficult when you might not need that lesson for another six months when you come to work on similar project or scenario. Your team need a repeatable method that they can use to produce estimates and learn lessons as they go.
- Build the estimating skill set within your team.
- Each person produces their own estimates for their own work*, which are linked to a set of KPI's. The over goal is to be accurate (not coming in under estimate or over).
- Split big tasks into small sub-tasks, and small-sized estimates. I suggest nothing more than four hours.
- Ask each person to track how long each task took and make detailed notes on why it took longer or less.
By using this method, the estimator will need to think about how to estimate better every day. They are analysing what went well and what did not, every few hours. They are building their own database of personal lessons and gaining a lot of valuable experience in estimating.
This also gives the project manager a progress report that is always up-to-date with estimates to complete the larger task at hand and plan accordingly.
* The estimates for tasks or projects cannot usually wait to be broken down into finite amounts by each individual who may work on a project. Stakeholders often need to move much faster on decisions. However, by separating top-level estimates (for decision making) from detailed estimates - which can only be done when you have detailed information and the budget agreement decisions to progress the tasks/project - you can still meet the needs of stakeholders' desire for information on costs, but then follow-up with much more accurate information during the project.
These two practices will give you and your team:
- Better code. Higher quality, fit for purpose, less debug and a more maintainable solution for future projects.
- Timescales with more certainty. Detailed estimates from experienced estimators.
- Happier stakeholders