Pages

Tuesday, 8 May 2012

How to implementation almost anything...

This diagram summarises (my own view of) how to roll out almost anything in IT that is not too technical - not an systems deployment, perhaps (which would be full of technical preparations and tests) but certainly a new process or function.



It's quite obvious once you've nailed down the detail, but you may find it helpful. The steps for each of these tasks are summarised below:
  1. Stakeholder workshops
    • Scope
    • Goals
    • Impact
    • Process
    • Expectations
    • Participation
  2. Finalise key updates
    • Functions
    • Organisation
    • Products
    • Processes
    • Controls
    • Training
    • Intranet
  3. Project kick-off
    • Scope + goals
    • Budget
    • Requirements
    • Sponsor + stakeholders
    • Mandate/Project definition
    • Issues + risks
    • Critical success factors + KPIs
  4. Communicate with stakeholders
    • Expectations
    • Impact
    • Budget
    • Alignment
    • Authority to proceed
  5. Identify audiences
    • IT stakeholders
    • Business stakeholders
    • Delivery managers
    • Development teams
    • Operations + support
    • Regulators & compliance
    • Cross-organisational teams
  6. Capture current status
    • Function mapping
    • As-is process/systems
    • Awareness & interests
    • Functional impact
    • Implementation impact
    • SWOT, risks & issues
  7. Validate roll-out process
    • Process walkthrough
    • Impact assessment
    • Participation requirements & plan
    • Risks & issues
    • Go/No Go decision
  8. Tailor roll-out packages
    • Local expectations + impact
    • Entry/exit points/processes/products
    • Current level of knowledge
    • Local implementation process
    • Local interfaces, access, reporting, etc.
  9. Communicate with SMEs & specialised functions
    • Expertise requirements
    • Participation in transition
    • Support during transition
    • Facilitation
  10. Train users
    • Functional objectives
    • Walk through solution
    • Metrics & standards
    • Participation in transition
    • Cutover impact
    • Supervision & support
  11. Train SMEs
    • [as for Train Users]
    • Brief stakeholders
      • Changes
      • Impact
      • Benefits/value
      • Transition process
    • Roll out components
      • Access tools & privileges
      • Localisation
      • Local integration
      • Measurement tools
      • Support arrangements
      • Remove existing systems/materials
    • Evaluate benefits
      • Take-up
      • Performance metrics
      • Quality metrics
      • User satisfaction
      • Transition costs
      • Stakeholder satisfaction
      • Compliance
    • Close project
      • Validate against requirements
      • Project performance
      • Update support
      • Residual issues
      • Lessons learned
      • Project closure
    Of course, this assumes that you have actually captured the requirements, modelled the process and design the implementation components in advance, which isn't always the case. But this process should at least tell you what you need to have done before you get to implementation.

    Your SDLC is your company's brain

    I have 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 the potentially area. 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 very good analogue of the an organisation’s development lifecycles. not least because it is the reason why we are by far the most dominant organism the world as 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 human 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 six) 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.
      • Is there a development strategy?
      • Is there real expertise in methodology development? Just asking PMs what they think is like asking drivers how to design a far – you’ll get some of the user requirements but nothing useful about the design.
      • Is there a coherent or proportionate rollout/update process?
    2. 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)?
    3. Does it cover all of your most important delivery strategies?
      • Outsourcing?
      • Offshoring?
      • Package procurement & implementation?
      • SAAS (Software As A Service – thinks like Salesforce.com)?
      • Does it have enough (or anything) to say about non-development activities?
      • Procurement?
      • Support and maintenance?
      • Technology upgrades (Oracle, SWIFT, etc.)?
    4. How mature is the lifecycle itself?
      • Are there proper delivery and management processes - i.e., some components exist, but they do not operate as a complete, end-to-end, Prince2-like 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?
      • Operational design, development, readiness & transition?
      • Does it handle very small projects (which can often be managed through a single artefact)?
    5. 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 include stage-end consolidation & validation, evaluate full project content, review performance to date or readiness for next stage, etc.?
    6. Are all individual products actually inadequate?
      • Are products defined by independent product descriptions?
      • Are there stage, product- and task-level procedures, advice & information?
      • Are there samples of good practice, including instances for each major area of usage?
      • Does each item have a supporting quality checklist?
    7. 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?
    8. 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)?
    9. 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 at least 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 to real intelligence.