Your lifecycle is your company’s brain

I was recently been asked to review a large insurance company’s delivery methodology, and found a state of affairs I have not witnessed for about 20 years. It’s a sad thing that major companies routinely neglect their lifecycles, methods and processes, presumably because they do not appreciate just how valuable they potentially are. It’s almost like they can’t see what good their brains do, so they neglect them in favour of other, more obviously useful organs (mainly the stomach, I think), and as a result their brains shrink and they become still less able to evaluate those same brains’ purpose, effectiveness or value.

In fact the brain is a very good analogue of an organisation’s development lifecycles. Not least because it is the reason why we are by far the most dominant organism the world has ever seen. From the point of view of development, I would say that an organisation’s formal processes represent about half its brain – a good deal of its memory, its practical skills, its controls for perception and behaviour, quite a lot of its capacity for reasoning about cause and effect, balance and coordination, and most of its basic language and social skills. Yet in many companies development lifecycles are organised and managed like the brain of a crocodile, not a human being, and while that continues it will never evolve into an intelligent being. (The analogy is more exact than you might imagine.)

But of course, the brain consumes about 20% of the body’s energy, while most development lifecycles would be lucky to receive 1% of a company’s attention. Which is odd, to say the least. Any improvement in process brought about by improving the local development lifecycle would surely need to change in performance by at least, say, 4-5%. In a £20 million programme, that means spending £1 million on their lifecycle would at least be covered – yet does anyone spend so much on this crucial part of development? As for a £100 million portfolio, how many companies pend £5 million a year on maintaining their development processes, let alone the central nervous system’s budget of 20%?

On the other hand, the efficiencies that could be achieved by integrating the delivery process as a whole and making it a dynamic part of real delivery are vast. Some time ago Accenture published a paper showing that training had an ROI of more than 350%, and I suspect that the same would be true of improving most companies’ development lifecycles.

Here is a quick questionnaire of the most important issues, based on about 20 years of looking at (and occasionally helping to fix) the problem. Note that it does not start with the details of the lifecycle documents and products – that is the least important fact! On the other hand, in more mature organisations the issue is often no more than obsolescence and missing items follow from the lack of sustained management focus, but in all too many cases there are major gaps.

  1. Is there a global management approach to the delivery process itself?
    • Clear unitary and controlled ownership, management & rules of delegation of the end-to-end development process.
  2. Is there a development strategy covering the scope and maturity of the overall development and delivery process?
  3. Is there real expertise in methodology development? Just asking PMs what they think is like asking drivers how to design a car – you’ll get some of the user requirements but nothing useful about the design.
  4. Is there a coherent or proportionate roll-out/update process?
    • Is there a simple, intelligible presentation & access?
    • A single, integrated model of delivery as a whole, including:
      • Governance, management technical tasks and support functions?
      • All stages, including both work selection and initiation and solution deployment/transition and work closure?
    • A single, user-friendly site for accessing the delivery process as a whole?
    • Effective control over authoritative versions (and withdrawal of obsolete materials)?
  5. Does it cover all of your most important delivery strategies?
    • Outsourcing?
    • Offshoring?
    • Support and maintenance?
    • Package procurement & implementation?
    • xAAS ([software/infrastructure/etc.] As A Service)?
  6. Does it have enough (or anything) to say about non-development activities?
    • Procurement?
    • Technology upgrades (databases, operating systems, tools, etc.)?
  7. How mature is the lifecycle itself?
    • Are there proper delivery and management processes – or do components exist, but do not operate as a complete, end-to-end process?
    • Is there a true programme management lifecycle (most organisations are dominated by programmes now)?
    • Does it include a convincing model of change management as a whole, notably:
      • Business design, development, readiness & transition?
      • Architecture?
      • Operational design, development, readiness & transition?
    • Does it handle very small projects (which can often be managed through a single artefact)?
    • How well does the lifecycle define basic management elements?
    • Roles + responsibilities – are they current, consistent and complete?
    • Are there explicit criteria, rules and authorities for adaptation, scaling & exemption?
    • Does it include (or at least point to) integrated stage and task-level processes & tools?
    • If it is a waterfall lifecycle, does it include a risk-driven iteration model for managing individual tasks and stages?
    • Are there detailed procedures for basic management tasks (risks, issues, assumptions, dependencies, change/configuration control, product/document management, impact analysis, estimating, planning, resourcing…)?
    • Have standard stage/task/product level risks, assumptions, dependencies, etc. been identified and articulated?
    • Does it set credible gateways, including stage-end consolidation & validation, evaluate full project content, review performance to date or readiness for next stage, etc.?
    • Are there stage, product- and task-level procedures, advice & information?
  8. Are all individual products adequately defined?
    • Are at least the key deliverables and interim products pre-specified in product descriptions?
    • Are there realistic exemplars covering a sensible range of variants for each major area of usage?
    • Is there a usable quality checklist for each one?
  9. Is alignment with other functions well defined?
    • Clear & efficient access to supporting management functions & data (resourcing, MI, finance, architecture, etc.)
    • Explicit alignment with and access to related standards + policies?
  10. Is the lifecycle actively supported?
    • Are there discipline or process owners, with clear roles & responsibilities, a proper management cycle and allocated time to do the job?
    • Are there SMEs, with clear requirements and channels for feeding their experience into the organisation (e.g., a central lessons learned system or training/briefing programme)?
    • Is there an R&D process (minimally to drive innovation, capture and socialise training and disseminate new joiners’ knowledge & experience)?
    • Is there a training programme covering all processes, roles, tools & techniques?
    • Is there a specialised SDLC training function & system?
    • Is there a training programme for staff, consultants, outsourcers, offshore & contractors?
    • Are there self-training packages for key activities – individual products, reviews, testing, requirements management, etc. – so users can refresh their knowledge independently and as and when needed?

Without a Yes to most of these questions, you have the methodological equivalent of a crocodile’s brain, and it will be all but impossible to make substantial and sustainable progress towards real intelligence without forcing real evolutionary leap.

By |2018-03-26T21:30:57+00:00Tuesday, May 8 2012|Categories: All, Capability, Process and method, Thought leadership, Waterfall|0 Comments

About the Author:

Chief Architect,

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?             
error: Agile201 is wholly copyright and copy-protected.