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 |
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
Software-Engineering-A-Practitioners-Approach
http://en.wikipedia.org/wiki/The_Mythical_Man-Month
No comments:
Post a Comment