Idea through to Delivery
I’ve seen too many IT projects fail and too many business-driven projects pushed into production only to give IT headaches. We need to stop this. Too often organizations operate with the approach that a half-thought-through idea leads to a corridor conversation with somebody in IT to a solution being imagined during the conversation, and then the solution being implemented soon thereafter which in turn leads to pain and headaches for the IT support teams. This needs to stop. The basic approach that needs to be followed is:
Ideas need to be recorded somewhere, probably as a request in the service management tool, assigned to an appropriate person or group of people, prioritized, requirements gathered, evaluated for impact to existing services / ongoing projects/resource availability and then given the go-ahead or not.
Capture
All ideas, whether fully thought through or not, should be recorded somewhere central. This may be as a non-standard service request (doesn’t fall into any option on your request catalogue) in your service management tool, or a separate database that you use for this purpose. Wherever it is, make sure it is recorded.
Review
An appropriate person / people should review these ideas / requests on a regular basis. This might be daily, weekly or monthly. Only you and your organisation can make this call. Whatever the regularity, ensure that you have criteria which the request is considered against, including whether the request enables the organisation’s strategy and/or your Service Strategy. This may help you decide quickly whether to proceed or not. It is also worth understanding whether the request is for a new service, or an amendment to an existing one.
Should you be in a position where you currently have a service portfolio, now is the time to start updating the service pipeline aspect.
Prioritize the request now and discuss this priority with the submitter. Maybe you have misunderstood the impact of doing / not doing the request and it needs re-prioritising. This initial prioritisation should be understood to be subject to change, as the pipeline, or your equivalent, should be reviewed by your governance group. It is the group responsible for the governance of IT who should agree which services are to be amended or added as they direct IT management on the deliverables. COBIT 5 puts it:
At this review, in conjunction with your governance group, it should be decided whether the request is going to proceed. However, at this point, you also need to consider people. Do you have enough people with the requisite skills to deliver the service?
High-Level Requirements and Design
Now you should ensure you have high-level requirements from the requester, which will enable you to produce a high-level design. This does not need to be any more than a diagram that shows the concept behind the delivery of the service.
Socialise
Now get the high level design reviewed by all support teams. Is it doable? Is it supportable? Is it worthwhile? If the consensus of opinion is that the high level design is satisfactory you should walk the customer through it. Check that this what they were thinking? Does it deliver against their high level requirements?
Detailed Requirements and Design
Yes? Great. Now drill down by gathering detailed requirements – functional and non-functional. Take into consideration not only the requester’s requirements but also those of all support teams too. They are also stakeholders. Produce a detailed design based on these requirements. Maybe there should be an ops advocate with the project who can work with the solution architect and the project manager, but that isn’t always feasible. If not, as a support team, make sure you find time to document your standard MINIMUM requirements (functional and non-functional) which can be provided to each project at the very start.
Socialise and Review
Review again with all stakeholders. Is it still meeting requirements? Is it supportable? Is the impact on other services understood and catered for? Carry out an operational impact assessment; can the operational support teams support what has been designed? Will they require training? Will they require more support personnel? Does the PM need to add this into the business case? Additional cost may require that. If the support teams are told they can’t have more staff, then that needs to be documented as a risk and signed off on by the governance group and all members of the project board. What will the impact be to existing services? Do those service owners needing to sign off on the headcount increase the chance rejection?
In the second part of this blog we will move on the the ‘build’, ‘test’ and subsequent phases of the change.
