The Hardest Part of Software Project Management
I have been a software engineer and project manager for over 20 years. Can you guess what I’ve found to be the hardest part of managing software engineer projects? It isn’t persuading the engineers to put aside their running shoes and holey T-shirts for customer visits. It’s not riot prevention when the coffee pot breaks down. It’s figuring out how much it’s going to cost to build the software and then persuading the customer that that’s really how much it costs to build the software. As a rule of thumb, if the price feels right the first time you hear it, it’s too low.
Why Is It So Hard?
Why is it so hard to create accurate software estimates? Software engineers are eternal optimists when it comes to estimation. A software project that costs as much as the initial gut feeling estimate would have to look like this: The customer knows exactly what they want and perfectly specifies their requirements in writing. They never change their mind. A team of the company’s three most productive engineers begin the project in a bomb shelter with no windows or communication with the outside world. The tools they need magically install themselves correctly the first time. No unexpected technical issues arise. The hardware is flawless. The software is written correctly the first time with no bugs and no need to test. There is perfect team continuity. No team members ever miss a day of work due to their own illnesses or to take care of sick family members (isolated in a bomb shelter, who knows if the family is sick?). The engineers are fueled by an endless supply of pizza, donuts, Mountain Dew, and coffee.
Of course, software is never built in the perfect, bomb shelter environment. There are technical challenges and hardware issues to overcome. Testing and bug fixing usually take more time than accounted for in the “gut feeling” estimate, if they were accounted for at all. It’s impossible and impractical for the customer to specify every last detail of the desired software up front. And as we all know… life happens to the software team.
These factors and others make it difficult to accurately estimate the size of the software before beginning the project. A quality software estimate created by an experienced software project manager which leaves enough time for the unexpected challenges nearly always feels too big to anyone who had an initial “gut feeling” estimate.
Advice for software customers
What does all this mean for you, the software customer? Perhaps you’ve requested estimates from one or more software engineering companies, and now you have a few proposals and estimates to choose from. If you go with the lowest cost and it was just a bomb shelter estimate, you may end up with an end of project budget crisis and be left with late, buggy, over budget software delivery. The larger estimates may be more than you hoped to spend on the software and outside your available budget. You also wonder if a higher priced estimate is justified. What to do?
Don’t be afraid to ask for details on how the software cost was estimated. A business with a mature software estimation process will be willing to share with you how the estimate was derived.
What can you do if the software cost is higher than your budget? Can you still move forward in a way that gets you partial functionality at a cost you can afford, yet doesn’t make unrealistic promises that the software team can’t deliver?
Yes. The answer is Agile. Agile is all about incremental development, frequent feedback, and collaboration.
A Closer Look at Benefits of Agile
If we define the smallest slice of functionality that is valuable to the customer (a minimum viable product, MVP), this can usually be built for a much lower cost than the full featured estimate. Incremental functionality is demonstrated to the customer to obtain early feedback. This has many benefits. As the customer visualizes the software, early feedback helps keep development moving forward on a path towards a product that the customer really wants, which may be somewhat different than what was originally envisioned. The flexibility and feedback of the Agile process lets you change your mind based on early experience with the software.
After the minimum viable product is delivered, features can be added incrementally. If the budget runs out, the customer will have a product which supports at least some of the features that they originally wanted. But they won’t be left with half-finished software which supports none of the features that they wanted.
Agile alone won’t make your software project perfect. You can, however, expect to have working software, sooner, that won’t blow the budget. And the best part is… no bomb shelter required.
Thoughts on how using Agile has helped your software delivery process? If you have insights on what has worked well for your team, or you want to share your own experiences, please feel free to comment below!