Software Delivery Policies

Some CTOs do not want to commit to delivery dates. Their rationale tends to be that there is too much unknown to commit to a date, resourcing changes or constraints might affect pace, and missing a date when a large part of the work is complete would demoralize the engineering team. I have typically had a different perspective where I feel it is the responsibility of all leaders to make delivery commitments so that expectations can be set, the teams that are affected downstream can plan, and we collectively know if things are “on track” or not as the project progresses.

I’m curious what other people have experienced in working with CTOs? Have you found a method or system that works for all functions?

Responses:

• We use delivery dates. It gives the company a deadline to work toward. I can’t imagine working at a software company that does not have hard deadlines to achieve for the reasons you state below and there are probably others to add. A lot depends upon project development methodology used by your company. For example, an Agile dev methodology focuses on incremental delivery each “sprint” (2-4 weeks) noting that requirements/priorities may change during the overall project timeline. Conversely a “waterfall” approach delivers everything at once (ex: a large ERP project). However, in any scenario a “roadmap” should show estimated future deliverables and approximate dates and manage to that. Additionally, some projects will require specific deliverable dates to plan/notify/coordinate with other teams (typically the end user that needs to ready to receive the deliverable). Obviously, there is a lot more involved, but the project management and change management teams should be able to provide both short-and longer-term deliverable dates and measure how efficient the dev teams are in meeting those dates.
• I completely agree with your perspective and have found that a lack of dates or milestones ensures the project will miss the ultimate deadline and budget. I will typically use a phased or milestone approach. This allows for the unknown to playout while holding the team to short deadlines, which also ensure the project is moving forward. I would definitely hold a CTO to a timeline and cost, at that level it is expected.
• Our VP of R&D implemented Commitment Based Program Management when he joined a couple of years ago. Prior to that the team just consistently failed to deliver.
• CBPM focuses on the concept of a deliverables map with card on it that capture the deliverable, who is delivering it and when and who the recipient is.

The other concept in CBPM is the “cone of uncertainty”. Using agile planning the objective is usually clear (make product X), but the path to get there is unclear. Earlier in the cone uncertainty is high (to the CTO’s pt…) but over time aspects of the program (based on the deliverables) become more certain. Below is a summary that I hope helps with context. Happy to discuss further and share books and tools we use if it will help.

Agile does just enough planning to figure out the next release and, more specifically, the next iteration or sprint. There’s an overall vision of where the project is going and there is some longer-term planning but it’s pretty fuzzy.

Similarly, CBPM focuses on detailed (at the deliverables level) planning for the next 6-8 weeks, the commitment horizon. It does look further down but the plan dates are estimates, not commitments.

• When I worked for a larger publicly held company, there were key milestones that had to meet for deployment dates. But, they also had (what seemed like) unlimited resources to throw at the projects.
• My large company experience was we always received a date and budget and the CIO or CTO never met the date or time. When we used to look to approve capex projects, we’d assume 15% more cost and at least 10% less benefits and then revisit the cost benefit of the project. The other option for you is something we started doing which was to ask for how much $ and time they needed to generate a good estimate. We’d authorize an initial spend to get a better estimate. Then you can approve incremental spending under agile sprints to keep the project from getting out of hand. I would be very suspicious of the inability to give an estimate. They could spend the company into bankruptcy, especially if the CTO believes they know what’s best for the business, but have no clue about the financial implications. Huge red flag for me if they can’t give an estimate for the project.
• I used to work with companies on tech where over 80% of the team was technical and CTO driven.

I often come across CTOs that have a very hard time committing to a date. Some of it is driven by an engineering mindset where CTOs look for > 120% validation (versus 80/20). Some of it unfortunately comes from politics where CTOs use an excuse of complexity to avoid responsibility.

Neither option works — businesses are rooted in deadlines and milestone achievement. If there is no deadline effective planning cannot be done. If you cannot plan, you plan to fail.

Get a date and tell them to get it done in time 🙂

• I had a background working in software and data firms over the last decade and currently am filling the CTO role on a temp basis until we hire one in Q3.

I think the answer to your question isn’t a straightforward one and the following are variables:

1. Does your team have a defined SDLC that they follow? If not that’s part of the problem
2. Does your team have a clear resourcing plan that includes keeping production running, bug fixes, upgrades etc.?
3. What method does your team use to estimate? (i.e., story points in agile) How long have they been doing it? and what is the leader’s confidence level in understanding each resource’s estimate?

These are all components that lead to being able to make confident commitments to the business. If your team doesn’t have these-don’t trust the answers.

• You don’t mention what development method they are using. If it is a waterfall method, any estimate wouldn’t be much value because it would certainly change. That’s a very outdated and inefficient development method so that’s not likely what is being used.

If they’re using an agile methodology, they should easily be able to tell you what will be in the next release. Releases should be every two weeks. If they do a good job grooming their backlog, and the organization doesn’t constantly switch priorities, they should be able to give you a sense of how many sprints it will take to get a larger portion of functionality completed. If it is new software and not an iterative improvement, the dev group wouldn’t be able to give you more than general timeframe targets but there should be milestones along the way that can inform how the long-term date is moving. As they get closer to the end, the estimates should get much tighter. They should easily know if they have four weeks or four months left.

• If a CTO told me s/he couldn’t give me an idea of a completion date for fear of demoralizing the team, I wouldn’t think that is remotely legitimate unless the punishment for not finishing is a mass firing which wouldn’t be the case. That sounds like an excuse for someone who isn’t willing to put a stake in the ground and drive toward it.