My last few blog articles have focused on process, and with this article I will continue down this path by discussing software scheduling, specifically how software scheduling should be a discussion of risk.
In a way all project management discussions can be discussions of risk. Without uncertainty, scheduling could be done by a computer. Software development is uncertain, and the degree of uncertainty is proportionate to the resources available and their familiarity with the software development technologies, their familiarity with the domain, along with numerous other factors.
To set the stage, let’s take a typical exchange between a project manager (non-technical team lead, technical manager, stakeholder, etc.) and a technical lead. I have seen many conversations that proceed as follows:
Project manager: We have provided you the requirements overview. Are you able to estimate the work?
Technical lead: Yes, it looks like 6-8 weeks of work.
Project manager: Can you commit to delivering it within 8 weeks?
Technical lead: Yes.
Project manager: Ok, I will communicate this to the customer. We have a lot riding on this, so let’s not mess up. Can you provide me some progress milestones along the way?
Technical lead: Yes, there are about 5. I will let you know as we complete them.
Project manager: Can we demo before 8 weeks?
Technical lead: Sure, we can demo progress every two weeks to the customer.
Project manager: Great news. Thanks.
There is a lot good to this conversation. The project manager and the technical team are interacting at the right level of granularity (i.e.: not at a day-to-day task basis). The project manager is not interested in day-to-day deliverables, but instead at a high-level view of progress (X/5 high-level features complete). Demos are scheduled in order to present progress to the customer. There is, however, something missing from this conversation: What risks are out there? We are making the project manager’s job too easy.
What if there is a 90% chance of delivering within 8 weeks, a 5% chance of delivering within 18, and a 5% chance of NEVER DELIVERING?
There are two things that could have happened here: The technical lead might not understand this risk distribution. Another alternative is that the technical lead understood this risk distribution but hid it from the project manager because 90% chance of success is good enough.
What is really happening here is that the technical lead is taking on risk that the project stakeholders and the end customer are not aware of.
Is this bad? Well, it depends.
Risk needs to be managed, mitigated, and worked into a business plan somewhere. There are many organizations, where the 5-10% chance of non-delivery is acceptably managed within a technical team. There are some organizations, where this 5-10% chance of non-delivery could have significant negative business impact and would be critical to be surfaced.
Instead of risks being managed by technical leads, risks could instead by identified, quantified, and surfaced so as to fit into a more holistic risk management framework. Within the technology area, one can look at the way enterprise security risk management has developed to gain an appreciation for the way technology risks can be managed, aggregated, and surfaced to business stakeholders.
It is important to allow top level technical leads a great level of autonomy. It positively impacts quality, schedule, and employee retention (based solely on personal experience). I am not promoting decreasing this level of autonomy, but I am promoting a more sophisticated communication about scheduling and risk of delivery between technical leads and project stakeholders.
Identifying a team’s top risks are not terribly difficult:
- What technologies are we planning on using that we don’t know well?
- What domain problems do we need to solve that we don’t understand to the extent we need to?
- Is there a lack of availability in domain expertise?
- Is there a lot of work we are not good at (i.e.: UI design, database optimization)?
- What is the degree of uncertainty of external dependencies?
- What is our gut feel about how much work there is?
So how does a team lead integrate these into discussions of schedule? To answer this requires a discussion of delivery estimation, which I may get to in another post, but is out of scope here. I will end with another example discussion, this time including risk:
Project manager: We have provided you the requirements document. Are you able to estimate the work?
Technical lead: Yes, it looks like a high chance of delivery within 6-8 weeks of work, but we should discuss risks.
Project manager: OK. What’s up?
Technical lead: Well,
- We are working with a new external API, and although we have done a PoC, we don’t know how reliable it will be once we start reliability testing. If this doesn’t go well, we could have up to another three weeks of implementation to achieve required reliability.
- There is a new required algorithm and a new data structure that we are not 100% confident we can fully implement without external help. We know resource Mr. Genius Quant Guy is very busy this release cycle.
- We have a new hire and although very optimistic, might not work out well. This could drain other productive resources more than we anticipated.
Project manager: OK, I’ve recorded these risks. What does delivery look like if any one of these occurs?
Technical lead: Three weeks, unknown, and two weeks respectively.
Project manager: What is an approximate chance of occurrence?
Technical lead: 25%, 10%, and 25%, but those are real ballparks.
Project manager; It seems like not having a resource for the algorithm is the most risky part of this project because of how long it could drag it on for.
Technical lead: Agreed.
Project manager: OK, thanks for letting me know. We will include you in discussions with the project sponsors when we decide how to mitigate and communicate these risks to the customer. Can you provide updates on overall progress?
Technical lead: I appreciate the inclusion, and yes, we have 5 milestones that we will use to track progress. These map to our 5 key features.
Project manager: Great. I feel like I have a good grasp on this. Now I just wish technical lead M would understand his deliverables as well. Let’s talk next week.
There are no hard and fast rules to being a good team lead or succeeding at delivering a project. If you are not discussing risk of delivery between those committing the business to deliverables (think $$$) and those responsible for delivering, a big piece is missing. The best software development teams are agile, however most projects require long-term planning and delivery commitments. When there is money on the line, treating development risks casually should be unacceptable.