Thursday, May 22, 2014

Why is software project management so difficult?

Everyone has read about the ninety-ninety rule. "The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time." by Tom Cargill, Bell Labs.
Total development time is 180% of budgeted.
McKinsey and University Oxford surveyed more than 5400 IT projects in June 2012. The study is not showing promising results for large scale projects and the picture is similar for smaller IT projects.

IT projects cost overrun
IT projects cost overrun

 
A couple of years ago I worked in real estate development, mostly constructions of commercial buildings and I didn't see these cost overruns which are almost symptomatic in IT. Especially some software departments are quite creative to hide total software project cost by accounting development cost under support or enhancement cost.

Why is it so complex and difficult?


IT projects Construction projects
- Modern software companies have teams distributed around the world, but they work on a specific project. - Construction happens at specific location with persons responsible at the same place (except tunnel projects).
- Software project progress is not immediately visible to stakeholders. It is virutal and intangible. - Construction project progress is feasibly even nonprofessional persons can understand the progress.
- A capable single developer can actually create an entire shippable product. - A single construction worker can't build a object.
- A lot of software processes start really late with acceptance and integration tests which shifts discovery of flaws within architecture or functionality. - Acceptance of progress of construction work happens often (basement, framework, per story, installation
- Different opinions about the right architecture - Architecture is settled when constuction starts.
- Scope isn't clear
Software is typically a process of discovery. Teams learn what needs to be developed as the product evolves.

Note: Construction projects have other pitfalls but tasks are easier to track.

What do I do to make them better manageable?
  • I prefer software process with short iteration cycles e.g. Scrum, Scrum extended with Kanban limits, typical spiral models with iterations depending on project size.
  • If I have to work within a specific process close to a linear model, I try to enforce a heavy testing culture
  • Being painstaking about a crystal clear scope and the understanding of the scope
  • Divide and conquer strategy (small parts are better manageable, integration as soon as possible)
  • Good estimating (Analogous estimating, three-point estimates and include probability)
  • Making the development visible by using whiteboards, Kanban boards, Standup meeting  per team (15min max)
  • Making the software development visible to stakeholders (management, tester, other teams, end user etc.)
  • Having a risk plan (risk, weight, impact matrix) and cost control in place
Links and Books:
Software-Engineering-A-Practitioners-Approach
http://en.wikipedia.org/wiki/The_Mythical_Man-Month


No comments:

Post a Comment