The five articles in this series have a single purpose: share small outlines of the approach I used in various consulting and service management activities.
This blog is also a “draft” for other publications, and therefore I decided to share also methodology segments, developed through activities.
Five activities, each activity with a 10-points “plan outline”, followed by a discussion on how that could be supported by a specific job position (that I either observed or helped to create).
The five activities are:
- crisis (resolution)
- contract (negotiation)
- confidentiality (monitoring)
- service (management)
- project (management)
The introduction to this article is shared with the article on “project management”.
If you read the previous articles you know where I am heading to- anyway, I rather add a shared preamble to explain my position on service and project management- and then move on.
Both service and project management share something else: from the 1980s, the increased use of heterogeneous information technology equipment, bringing computer use in every office, and not only for monthly processing.
With the spread of multi-vendor information technology, the methods and approaches imposed by vendors started being replaced by customer-sponsored standardization initiatives.
For reasons that I discussed often along my career (as recently as last week, when asked which role I preferred), I observed often overlaps between the two and I will discuss this overlap in the introduction.
While each one requires a specific focus on a different type of “compliance” and approach in budget and people management, a little bit of knowledge on how a project could generate a service or, viceversa, how a service could “spawn” projects is, in my experience, beneficial to the managers involved.
preamble and disclosure
By starting to work project and service management activities between late 1980s and early 1990s, I avoided being asked to which methodology I was “loyal”.
For the sake of brevity, I would say that, while I used, defined, sold, coached on methodologies and processes ranging from software analysis and development to project and service management and audit, I am agnostic.
More than once I saw that the largest customers used an hybrid, derived by their experience and, as I discussed in the article on confidentiality, with the clear intent to reduce their own operating costs by benefiting from using something that had a broad market presence- without being captive of a single vendor.
In the 1980s, beside the Andersen’s methodology Method/1, with each customer I had to use its own definitions of phases, acronyms, standard documents, etc: fine, if you stayed 10 years on the same site, as a some consultants that I met early in my career.
But a nightmare if, as I had to do on DSS/EIS and management reporting, you switched customer almost on a daily basis.
A long-term assignment allowed both suppliers and the customers to invest on acquiring customer-specific knowledge, to ensure a smooth integration.
As an example: in my first mainframe project in 1986, I had to attend training at FIAT on the IBM Data Dictionary- I never used it again in my life, but I was required to attend the training, as usually whoever started working there on a project… was there years later.
From the 1990s, I worked on expanding the use in Italy of MERISE, a French methodology (highly prescriptive and based on the assumption that, as in France, everybody knew it) and localize Yourdon (loosely descriptive, and open to external contributions).
Andersen’s methodology was anything that could be useful anywhere, and covered from project management to service management, and from “waterfall” to “iterative”- a kind of agnostic methodology (albeit with strong links with IBM concepts, dating back to the development of a software called CICS).
For internal economies of scale, it was, nonetheless, highly prescriptive, as this allowed a world-wide reuse of consultants and documents/experience, and the aggregation of post-mortem from products and services in a centralized office.
standards and consolidation
Between mid-1980s and mid-1990s the activity on methodologies was quite “ebullient”, and larger organizations, including governments, saw the benefits of avoiding a re-invention of the wheel.
And the same happened with the ISO 9000, CMM from SEI, and other approaches and frameworks.
The UK government saw the benefits of adopting a set of shared approaches, eventually to evolve into methodologies with structured processes- and, due to its size, eventually also the private sector started adopting those standards.
On service management, I am obviously referring to ITIL, a library of best practices- a descriptive approach.
Developed for IT Service Management, it has been used in many other different environments as a useful framework to avoid re-inventing the wheel on how to manage a service- any service, not just IT.
It is currently at the third release (V3, 2007; the first one was 20 years ago), while a new release is planned for 2011.
On project management, PRINCE2 (PRojects IN Controlled Environments, launched in 1996) was similarly developed in the UK; the version used in most companies is based on the 2005 release, which adopted a more prescriptive approach, if compared with the main alternative, PMI/PMBOK.
In 2007 was published MSP (Managing Successful Programmes), with a focus on shared guidance and best practices (e.g. on stakeholders management and cost/benefit)- descriptive, more than prescriptive.
The latest update of PRINCE2 in 2009 shifted toward a more descriptive approach, with role-specific suggested competencies and guidance for project sponsors, covering also project environments (PMI, being more descriptive than prescriptive, used to give a better perception on ancillary activities, such as purchasing, as it did not need to codify each activity).
This long shared preamble is just to explain the evolution of methodologies, and why I will use as a reference three published by OGC- MSP, ITIL, PRINCE2.
Due to the worldwide expansion of their use, there are ongoing projects to introduce elements to cover issues such as governance (COBIT, TOGAF), quality (Six Sigma, ISO 9000), security (ISO 27000), or approaches proposed by vendors (e.g. the Microsoft Operations Framework).
I will use as a reference three key definitions from OCG (see their knowledge-sharing websites linked to www.best-management-practice.com for more information and free whitepapers).
- programme (OGC Glossary v06, March 2008)
- A temporary flexible organization structure created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organization’s strategic objectives. A programme is likely to have a life that spans several years.
- project (OGC Glossary v06, March 2008)
- A temporary organization that is created for the purpose of delivering one or more business products according to an agreed Business Case.
- service (ITIL V3 Glossary V01 May 2007)
- A means of delivering value to Customers by facilitating Outcomes Customers want to achieve without the ownership of specific Costs and Risks.
Of the three, the less satisfying one, from my point of view, is the service: it is wide enough to remove the economic element (i.e. time x resources) as a basic tenet- while instead service delivery requires a definition of both the service- and its boundaries: time, resources, response time, etc.
To conclude this preamble, a useful short free bibliography (visit the OCG’s knowledge-sharing website to download the documents).
- “ITIL: The Basics” May 2010 (5 pages)
“Managing and Directing Successful Projects with PRINCE2” June 2009 (8 pages)
“MSP®: The Basics” May 2010 (7 pages)
- With a view on governance
- “Aligning CobiT 4.1, ITIL V3 and ISO/IEC 27002 for Business Benefit” 2008 (131 pages)
“Cross-Reference ITIL® V3 and MOF 4.0” (MOF stands for Microsoft Operations Framework) September 2009 (33 pages)
“Scope and Development Plan: ITIL v3 Update” February 2010 (8 pages), an example of a project’s organization and approach to improve what is, in the end, a service- ITIL itself (due out 2011)
using standards in the real world
My basic suggestion is: does not matter if you are a project manager, a service manager, or just a sponsor or customer for a new project or service.
Reading the few (free) documents listed above would give you a peer-reviewed and certified Wikipedia-style introduction to programme, project, and service management- and their impact on your activities.
I had in the past produced documents to summarize various standard approaches and approaches covering the same issues (from Sarbanes-Oxley, to ISO 27000/BS7799, to .Net architecture and session management/data exchange on Internet for service-oriented activities) as part of my coaching activities.
But it would require too much time to post an updated version, and therefore I invite you to search on Google or some of the communities on service and project management (search in Linkedin: there are some useful groups willing to share experience and advice), after reading the documents listed above.
services and projects
How comes that a project might generate unintentionally a service, or that a service might generate one or more projects?
In project management, people talk about “creeping scope”- an unwarranted scope enlargement introduced by seemingly innocent requests.
In service management, there is often a natural tendency to expect that the suppliers adapt the service to the expanded needs- but with no influence on price.
It is a constant struggle between the efficiency, needed to keep the suppliers (on both projects and services) operating at a profit, and maintaining efficacy, by adapting to current needs (even more critical for long-term activities).
And this applies both to internal suppliers and internal customers..
You probably heard of “emerging programmes”, projects that spawn other projects, and eventually the issue becomes coordinating all the deliverables and overlapping timelines (along with the expectations of the stakeholders).
Sometimes this is intentional: I myself managed more than one project with the mandate to deliver a “proof of concept” for a partner or a customer, to show, both in change management and software/technology to the stakeholders that it made sense to expand the budget and the scope.
And the same applies for services: how do you define a new service without first testing it?
I agreed sometimes with customers to set up a new service using part of the allocation under an existing service management contract, so that we could tune up the processes and resources needed, before negotiating a binding Service Level Agreement based on assumptions.
But you can also have “emerging projects” (from services) and “emerging services” (from projects).
I will present some samples under the section “position”.
Generally, it is a matter of managing the budget and identifying the boundaries, while managing the expectations and being transparent about the balance between costs and benefits: you cannot change the benefits without altering the costs (I will skip the usual reference to perpetual motion and thermodynamics).
budgeting and controlling
After observing directly and indirectly up to the early 1990s (and also thereafter) the damage on business relationships generated by the misalignment in communication (the “emerging” without appropriate preliminary budget approval), I always focused on a transparent separation between service and project.
I must admit that my approach is deformed by two activities- working on decision support systems and executive information systems almost at the beginning of my career (after toying with AI-based decision support few years before), and writing first a budget for my first project (mainframe), before writing my first line of COBOL on a real project.
Therefore, I learned about the cost of what I was going to do and the impact of each action that we took before actually doing it (usually it happens the other way around)- and then I followed the project end-to-end, basically adding a new role every few months, up to the system test.
From my first project in late 1980s (a KPI system to monitor a network of agents for the controller of a financial company), whenever I had budget negotiation and/or management authority, I clearly linked each objective (be it a service definition/management/delivery or a project/evolution) to specific budget lines.
Aim: to be able to discuss with the customers or buyers on costs and benefits (and resource allocation) using terms of reference shared with my counterpart.
The customer does not care if a software program to deliver a certain report is composed by 10 or 20000 lines of code, one or ten programs: (s)he wants the report- and when needed, not one week later.
And does not care if to answer a question my team has to talk in some cases with two people, or contact other suppliers: (s)he expects to receive an answer in a timeframe that is consistent with her/his needs- and that we agreed to while negotiating the contract.
By focusing on the need, I could then start from the purpose, identify the resources, and negotiate the purpose based on the resources available (I am used to work on fixed price or, in services, outsourcing or a pre-defined budget).
Whenever I had to negotiate a contract for a project or a service, I might have started from the existing budget or what the customer was willing to spend, but I always ended up with an offer covering time, resources, and budget lines associated with each result to be produced.
This approach allows tracking your budget, and, should the budget need to be re-financed (e.g. a new project to add features, or renewing a service), it would allow to carry out a fact-based negotiation.
In my definition and experience, I see a service as something set up with a series of processes, based upon a shared base of knowledge (potentially increased by the service delivery), and structured around an efficient allocation of resources.
“Efficient allocation of resources” means at least these few things:
deliver what is agreed in the Service Level Agreement and ensure that the supporting Operational Level Agreement/Escalation procedures are followed
solve, whenever feasible, any problem by the first one being informed of the problem
keep track of the information exchanges up to the resolution, if you need to “invoke” somebody else
manage knowledge, so that those delivering the service can do their job: it is critical to deliver as much knowledge access, training, coaching (increasing level of cost) as needed- no more
synchronize knowledge-transfer, so that what is used constantly is transmitted via training, the forma mentis is created via coaching, and everything else is available when needed
monitor constantly the level of satisfaction of the customers and the level of efficiency (as described above), to identify further knowledge-transfer needs, procedural changes, or initiate an update of the SLAs etc
In defining a contract for a service, I adopted the approach that, long ago, was explained to me by auditors and former auditors on how they used to deliver their services.
The first step, is studying what the environment, and the contract has to work through cycles.
In services, the minimal cycle that I usually proposed is a X-year contract, X depending on the environment, where the first year is to deliver the service and tune the SLAs; whenever feasible, I prefer to identify standard “service units”, and budget the resources on the amount of “service units” sold.
This allow monitoring in real-time of both the real resource allocation and potential trends, i.e. forecasting and dynamically allocate resources when needed.
Why X years? The first year, beside the tuning, is also in effect a study on the supply chain involved both in delivering the service, and using the services, and it is in effect part of the investment on the relationship.
The return on that investment is embedded in the margin delivered by the activities over the contract, as almost no customer is willing to pay for a trial at the full price (i.e. covering the consulting cost, as a recovery of the investment in developing the intellectual property used in doing the study).
The disengagement from the contract should be clearly tailored to the specific service and environment, both in terms of notice period and knowledge transfer practices.
As an example, in phasing out a service, you could agree on exporting the data in a specific format but, if the service is outsourced, transferring a copy of the database is not an option, as this would imply transferring to the next supplier the intellectual property (internal processes, database structure, and so on) of the current service provider.
- adapt to the environment you have to profile not only the users, but also the complete supply chain that will be involved in using, delivering, and maintaining the continuity of the service
- set key performance indicators (KPIs) after profiling, defining a limited set of parameters to monitor the service efficiency (for the service provider) and efficacy (for the service consumers), and include the KPIs as part of the SLA- should be attached to the contract (usually subject to periodic revision)
- identify a unique gatekeeper identify and agree with the customer the gatekeepers on both sides of the relationship- the service provider and the customer, as solver of last resort
- define the internal structure clearly define the roles within the service team, and the communication channels with those in the supply chain that would be involved for escalation or revision of the service structure or content, or disaster recovery activities
- communicate early and fast it is the role of the service manager to receive from the service team leader(s) what (s)he needs to identify potential critical issues to discuss with the service gatekeeper on the customer side- beyond the KPIs agreed to in the contract
- preempt key issues the service manager should constantly communicate the service status and proactively identify potential issues (e.g. new training needs)
- keep looking evolution at the boundaries a service is not delivered in a vacuum (albeit contracts tend to assume so): a service manager should monitor evolutions that transcend the control of either the supplier or the customer, to identify and discuss potential changes to introduce
- ensure continuous improvement a service starts on a status quo- the more it is used, the more the service itself could be focused: but this require monitoring both its delivery and its use
- report regularly and with structure communication should be a constant practice- increasing communication only when potential issue arise is the best way to ensure an uncooperative behaviour from the parties involved
- keep an eye on fall back and continuity keep monitoring the supply chain and, if feasible or needed, do drills periodically- your plans to manage the unexpected are a paper tiger if the supply chain they were based on disappears
I already hinted in the “outline” to the different roles assigned to the service manager and the team leader(s).
The first one is obviously in terms of scope and depth: a team leader should be able to lead by example- i.e. by sharing the knowledge, and usually is somebody who comes from the same type of activities at the service delivery level.
A service manager, while able to understand the service and (re)negotiate when needed, should communicate with the team leader(s), to identify additional information that could influence the service delivery or evolution.
Typical activities include ad hoc reporting on specific incidents, monitoring processes, and carrying out QA activities, or joint audit activities or inspections with representatives from the customer side.
A service manager should delegate power to the team leaders working everyday with the teams, and therefore focus on coaching the team leaders and improving their communication and resource management skills.
In the end, the service manager should focus on the efficiency, while team leaders should focus on efficacy within the efficiency boundaries set by the service manager.
In my experience since 1986 a full-time service manager staying in the office (the typical layout was a glass wall separating the service manager from the teams) is often counterproductive.
In the “glass wall” organization, service managers in effect risk undermining the authority derived from leadership of individual team leaders, by being tempted to intervene on individual events without having the whole picture leading to the event, leaving the team leaders to second guess the potential reaction- i.e. converting, in some cases, the service manager into a second team leader.
Whenever I saw “emerging projects” in service delivery environments, the reason was quite simple: nobody had the perspective to identify that there were service innovations that started as details, but required significant interventions and budget allocations.
And once a project is started, it might be that the resources needed to produce a solution that can be used as intended would require a significant budget, or would be simply not usable (e.g. because it assumes that temporary constraints on some information or processes are permanent standards).
Actually: I observed sometimes mini-projects that were gradually created on the service delivery side by requests from the users, simply to bypass the IT process to authorize new projects.
Separating the service manager from the team leader(s) allows to keep two different perspectives- a focus on details and day-by-day activities (the team leader), and a focus on the overall service (the manager).