Delivering to the Solution vs. Delivering to the Customer

Sad puppy wearing a gift-ribbon.Many of us have seen it. The notorious “black box” is dropped into the rack, plugged in, powered up, and once a few pings and system or application checks are completed, the project is declared “delivered” and the team quickly disappears.

Eventually, of course, something goes wrong and in many cases an already overworked support team needs to learn on the fly as they analyze and resolve a problem with a new application or service.

Fortunately many project delivery teams maintain a post-implementation support/warranty period where such events are resolved as a cost to the project, versus using steady-state funding (or internal IT budget) set aside for ongoing operations.

In such cases, specialist teams remain on-call and (perhaps most importantly) funded to assist with these last minute integration and support issues (while providing additional training and knowledge transfer to the support teams in the process).

This is fine until either the funding for the post-implementation support dries up, or management declares the new product to be in “steady-state” or “production” mode.

Often this “transition” decision is based upon various technical and training factors (such as a significantly error free period, or sufficient knowledge transfer from a vendor or key specialist to “Joe” who manages the boxes in the server room).

When problems occur post-implementation, a lack of effective operational readiness and transition to production planning can become a nightmare for Joe, the support teams and the IT organization at large.

Delivering to just the “Solution”

Projects are essentially just the manifestation of the deployment of a “solution” to some customer problem. It must, of course be tangible as well as both resource and time constrained.

The problem, however, is the solution is usually defined in the vacuum of an idealized model, or (if you’re particularly lucky) within the overall environment and related systems at the time the “solution” was negotiated and designed.

While this solution often addresses the key architectural and technical specifications necessary to complete the design, build and deploy for the project – it remains predominantly technically focused, and fixated on the point in time the solution was developed.

While your solution may be built in accordance with the specifications, and appears to pass all acceptance tests when plugged in, it has actually only started the first phase of the overall delivery process to the customer.

Delivering to the “Customer”

The “customer” exists in a dynamic environment, with requirements which go beyond the pristine model of any initial solution.

Not only has there been changes since the original solution design which need accommodation (i.e. inter project dependencies, new initiatives, changes to the baseline infrastructure, etc) but the customer’s total needs are rarely satisfied with just connecting a product to a socket in the wall.

Ultimately the new product or service being deployed will become part of what ideally is a thriving business, and it sometimes helps to think of it in this “living” context.

Essentially you’ve not only brought a new puppy home, but now you have the added problem of its care, feeding, watering and cleanup.

Multiple Customers/Consumers

Before you can assess what is required to successfully support the application, you need to identify the customer.

As with most projects and stakeholders, there are many “customers” to whom the solution is actually delivered – often generating supplemental deliverables above what was contained in the original specification/solution.

There are, of course, the ultimate end-users of your solution; but they are just one component in the overall delivery. Key service and support teams also need to be viewed as customers, and must have their requirements analyzed in order to determine what’s needed with the delivery of the solution.

For example, Joe and the support team will require manuals and configuration guides; the service desk may require quick reference cards and end-user documentation.

The requirements go beyond just documentation however, as the care and feeding model still applies – interfaces with existing service and delivery support processes and procedures are also required.

The puppy is more than just a “deliverable” to the kids (along with a copy of “Puppies for Dummies”); the sanction and support of other key “stakeholders” within the family is necessary in order to maintain unity – whether it’s Mom agreeing to deal with the extra pet hair around the home, or Dad walking Rover while the kids are at swimming lessons after school.

The new “box” delivered to the customer must fit within the overall operational context of the IT and business environment at large, and if it doesn’t fit – then either the box or the business/IT support organization needs to change.

Certainly some of these factors may have been considered during the initial design of the solution (i.e. where the box was to be connected and assigning it a network address), but the longer term requirements must also be accommodated. This becomes part of the management of the production or steady-state environment – such as network capacity requirements as the user base grows, or the space and time necessary for backups.

While everyone knew the new puppy needed a dog house, and Dad started to build one as Mom and the kids were getting the new dog, there could be significant problems if someone neglected to mention the puppy the kids settled on was a Great Dane.

But we already have an activation checklist…

Many organizations already have system activation checklists which outline the necessary steps and agreements necessary for installation of a new system or service – but these are largely technology focused. Transition to production activities, and eventual operational readiness, must take a larger holistic view of how the new solution fits within the overall business and IT environments.

This view should go beyond the initial parameters of the project; an overall product/service lifecycle needs to be considered – from the installation/initiation of the solution, to ongoing maintenance and support (the care and feeding), and to its eventual retirement.

Other business domains are also implicated (i.e. human resources and staffing, training and financial management; questions of what the cost of ownership of this new service will come up, as well as a determination of who owns the burden of those costs, etc).

Viewing the hardware or application as a service that must fit within the overall service framework of the organization is a great start. Working within ITIL’s[1] process framework (even if not an ITIL shop) can be an excellent start-point when assessing the overall requirements and impact on the organization.

For example, borrowing from the ITIL processes [2]

Service Support Processes

  • Service Desk/Service Request Management
    • Who will support the new box/service? Do the end-users know how to contact Support?
    • Is Support staffed sufficiently to answer calls about the new service?
    • What service requests might they receive, and are there processes/procedures in place to provide for these requests[3]? Who approves them? What are the associated costs, and who bears them (see Financial Management)?.
  • Incident & Problem Management
    • What is the end-to-end path for dealing with service outages and systemic faults? Are all parties aware and integrated with appropriate agreements, standards, tools, etc.
    • Is this consistent with support processes for other systems/services? Does it need to be an ‘exception’? Have the implications been considered?
    • Are there escalation processes to deal with more urgent situations or excessive delays?
    • Are there knowledge base/materials to assist teams in supporting the new application? Has a process been established to capture lessons learned and solutions to known problems?
  • Release and Configuration Management
    • Have appropriate processes been established to deal with modifications and upgrades to the application or service?
    • Are they key stakeholders known? Have formal approvers been identified within a change management process for this solution?
    • Is there a communications process/strategy in place?

Service Delivery Processes

  • Service Level Management
    • What are the customer expectations in terms of service availability and support? Are these formal, contractual commitments?
    • Can the Service Support processes, procedures, staffing and capacity actually meet these commitments? What are the implications if they are missed?
    • How are service levels being monitored and reported? Have the key performance indicators been identified?
  • Capacity and Availability Management
    • How are capacity and availability being monitored?
    • Who is responsible for expansion (or reduction) of the environment/service?
    • How do availability and outage metrics get integrated into overall service level and continuity management?
  • Continuity Management
    • Is there a disaster recovery plan in place? Has it been tested?
    • Are there backups being performed, and have they been properly integrated with other backup and continuity practices in the organization?
    • How quickly does the customer need data restored? How soon must the service be restored in the event of a total failure?
    • What is the overall cost/impact of an outage[4]?
  • Financial Management
    • Are the costs of the system known and understood?
    • Have these costs been incorporated into the annual operations budget, or has a cost-recovery/billing mechanism been put in place now that the product or service has gone live[5]?

Development of your own checklist of transition to production/operational readiness evaluation criteria, customized to the specifics of your organization, will go a long way to facilitate future delivery planning.

One great approach is to look at the formal definition of each of these ITIL services, and then perform a “so what?” devolution/analysis, but this is better left for a future article.

It should also be stated that not all the answers to these questions are going to result in action items for the project team; some go to the core of how operations and services are maintained within the IT organization at large – and become a larger, organizational problem to resolve.

Who’s Responsible?

One of the largest points of contention is the responsibility for planning and development of the transition to production deliverables. Does it reside with the steady-state teams required to ultimately operate and support the new service, or with the project team who delivered it?

Candidly, it’s a mix of both; however the burden of responsibility should rest with the team introducing the change to the steady-state environment – the project team.

The steady-state teams should be responsible for setting the standards and facilitating the planning for transition. Ultimately they should be serving as gatekeepers into the production environment – ensuring anything newly introduced is ready, and will not destabilize the environment or operations.

If this occurs, acceptance into steady state should be rejected until either the discrepancies are remediated (by the project), or the project team has a plan to mitigate the potential risks (which may even include “acceptance” by the gatekeepers of the steady-state environment).

Conclusion

Delivery merely begins with plugging in the new system or service, and the efforts in planning the overall transition to production and ensuring operational readiness may be comparable in size to those involved in the design of the solution.

One of the hidden costs that often impact an IT organization is failing to recognize the project’s commitment to complete this transition process.

Failing to plan is planning to fail, and in the context of operational readiness this failure can haunt the steady state teams throughout the entire operational lifecycle for years to come.

That cute little puppy the kids lost interest in eventually became a full sized dog that is now the whole family’s responsibility to care for.

[1] The Information Technology Infrastructure Library (ITIL) is a set of concepts and practices for managing Information Technology (IT) services (ITSM), IT development and IT operations. The names ITIL and IT Infrastructure Library are registered trademarks of the United Kingdom’s Office of Government Commerce (OGC). [cited from Wikipedia.org – http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library]

[2] Yes, I’ve taken some liberties by combining several processes and simplifying them in these examples.

[3] Think about password resets, new accesses, termination of access, etc – the list grows pretty quickly from there.

[4] You’ll need to know this if you want to prioritize repair efforts when multiple systems go down.

[5] I’ve seen new systems deployed where someone forgot to advise the finance team and thousands of dollars in revenue were lost before someone finally caught on there were monthly recurring charges to the customer missed with activation of the new service.

Author: Stephen Holton, PMP, CISSP, SSGB, ITIL, CD

After completing over twelve years service in the Canadian Armed Forces, Stephen moved to private industry where he was employed as a Director of Information Technology, Director of Operations and CIO for a number of private sector companies before finally electing to become an independent consultant in 2000. Since then he’s served as a management consultant, project/program manager and business analyst/solution architect in a number of industries and organizations - including a big-5 consulting firm. These industries and organizations have included the airline, railway, telecommunications and banking industries, the Canadian and US Governments, as well as mandates in Brazil and Bermuda. Presently Steve lives in Ottawa, Canada.

Leave a Reply

Your email address will not be published. Required fields are marked *