Save £12 Million every year > Save £3 Million every quarter   
The Big Agile Toolkit: no Dogma, no Bias, no Accreditation, no Exams & no Fees   
 Agile Conclusion  Agile Conclusion   Why Transition to Agile Now   Why Transition to Agile Now

Conclusion   »   Agile Conclusion   »   Why Transition

Software development companies can achieve huge margins on development projects. They are often an attractive lucrative proposition for corporate financing and company purchases. Software companies though must re-invest profits to gear up their standards, infrastructure and their people to match the latest environments for projects and developments. However in the wider business community, the software development industry is routinely judged to over promise and under estimate when they deliver business software solutions.

Companies over-promise as their sales personnel seek to meet the expectations of the latest customer sat in front of them. However, especially at the sales stage, the customer seldom fully understands what they require or need to achieve and they have little recognition of a successful outcome or any real visualisation of what this success looks like. Their projected expectations are aspirational and the definitions of these aspirations lack depth. On this basis it is not surprising that the estimate of these aspirations will tend to be off centre.

Project estimation is always an approximation of the process and the production of outputs involved in delivering the customers aspirations. The essential knowledge and data that are need to accurately establish a price for this delivery are not in place at the early stages and can only be derived in measured depiction when the wider extent of the work is uncovered.

As work is uncovered, though, it will routinely change. It will change because your business, our business and everybody elses business change through time. The rate our businesses change now is much faster and the frequency of changes is greater. Even a desperately short period of time will influence business now, more than it ever did before. Moreover, the work will change because the very nature of uncovering the work reveals the actual operation of the organisation and the true path of business processes. Therefore some of the original aspirations recede as new redirected as yet un-estimated demands arrive and are added to the delivery agenda.

Rapid changes often demand rapid responses. These responses mean changes to organisational processes, schedules and traditions. A rapid response though is often performed with much haste and much less finesse. It means that an organisations wiring is ripped out quickly and reconnected in a different hastily organised composition. It means that certain wires, less important to the organisation, are left to be reconnected later. Or the wires are sometimes left disconnected, seeping voltage, in the style of the organisations resources, down to earth. So, as this work is uncovered it will routinely reveal this type of waste. The opportunity to remove waste is routinely taken during the project mid-stream. It is given an associated priority and yet more un-estimated demands are added to the delivery agenda.

To accommodate this remit of expanding demands, an organisation will routinely evaluate its burn rate and costs to date on the project to determine its profitability and likelihood to cover delivery and break even. In commercial software development scenarios the organisation will also evaluate the latest financial estimate provided to the customer to establish if there is going to be an acceptable profit or ample meat left on the bone.

The conventional response is to take a new estimate back to the customer with justification for the added costs involved in work to remove or block off defunct or redundant organisational processes as well as the new effort to deliver extra consignments of new functionality and the changes to the original scope and features. This latter activity is no small feat either.

By the time a traditional project has got underway, the specifications as well as acres and acres of other project documentation have been produced describing the project and the business at that specific point in time. But we have seen business change and change very rapidly. All this documentation will need revisiting to validate and match any alterations and rework needed as a result of the new mid-stream changes demanded.

Good news for a delivery company as it means more work, more revenue and new or extended contracts. Bad news for the customer organisation as it means failed expectations, altered outcomes, more cost, more funding, more payments, more administration, more delay for realised benefits, more communication to stakeholders to describe and agree the new changes and so on and so on.

Change control, the bane of the customer whose project uses traditional methods, is enacted across the project and the customer is beseeched for more funds and more time to complete the extra work. The project has immediately gone over budget and over time. Another project failure statistic is born and another bone fide excuse for not funding wastrel IT projects dawns. In this way, you can see, the industry is killing itself very slowly and with each individual failed project is another slash of the blade.


 Agile Conclusion     Agile Conclusion   Why Transition to Agile Now    Why Transition to Agile Now

Glossary:     a  »   b  »   c  »   d  »   e  »   f  »   g  »   h  »   i  »   j  »   k  »   l  »   m  »   n  »   o  »   p  »   q  »   r  »   s  »   t  »   u  »   v  »   w  »   x  »   y  »   z

#personas  »   #artefacts  »   #archetypes  »   #patterns  »   #change  »   #personas  »   #increasingoutput  »   #reducingvariation  »   #improveefficiency  »   #abstraction  »   #predictionandcontrol  »   #management  »   #organisations  »   #socialnetworktheory  »   #failfast  »   #quality  »   #waste  »   #complexity  »   #learning  »   #adapt  »   #inspect  »   #improvement  »   #models  »   #complexadaptivesystems  »   #informationflow  »   #sytemsthinking  »   #butterflyeffect  »   #unpredictability  »   #chaos  »   #emergence  »   #emergentbehaviour  »   #distributedcontrol  »   #continuousimprovement  »   #complexityscience  »   #gametheory  »  
 Agile In 6 Steps    |    Projectivity    |    Instant Agile    |    Risks    |    Auditing Agile Projects 
Big Agile Toolkit Book (Amazon Japan)   |   Big Agile Toolkit Book (Barnes and Noble)
Buy the Big Agile Toolkit Book   |   Buy the Big Agile Toolkit Kindle eBook
Why Transition


The Big Agile Toolkit

 SPADE: Successful Pragmatic Agile Delivery Everytime™ 
Topic: 409  Page: 412/444  Progress: 92.8%
 About    |    Author 
Follow @BigAgileToolkit

This content can be copied to third parties for personal use if you acknowledge the source of the material with website URL ( and Twitter hashtag (#BigAgileToolkit).
In all other cases, no part of bigagiletoolkit or associated text or website may be copied reproduced or redistributed in any form or by any means without prior permission in writing from the author.
Agile Project Governance for Cost Conscious Companies™

All rights reserved.