By Blake Ragsdell
There is a quote attributed to William Shakespeare that says, "Expectation is the root of all heartache." While he may have hit the nail on the head, theatrically speaking, when you are responsible for leading a business, you must set expectations in order to thrive. So, with apologies to the bard, I am going to modify his quote to say, "Unreasonable expectations are the root of all heartache."
Expectations—How do I learn what is appropriate?
Whether you have a background in systems development, project management, business analysis or any other specialty, it's difficult to avoid hearing about the importance of setting expectations. But if everyone knows about its importance, why doesn't every project meet its expectations? Perhaps most relevant, how do you set appropriate expectations?
Expectations are tied to setting proper goals and objectives. For this article's purposes, we will stipulate that goals are the agreements forged between stakeholders about a project's outcome. Highly specific goals are best because they are the easiest to measure. So, clearly, stakeholders set the definition of a project’s success but they are also the group most likely to be disappointed by a project’s failure to meet expectations.
To minimize project risk, first make sure your stakeholder list is complete and everyone on it is involved. If you identify a stakeholder that doesn’t want to participate, you have three choices. You can lobby them to participate, you can enlist senior management’s aid to bring them to the table or, as a last resort, you can list their lack of participation in your project charter as a risk. By definition, if your project’s outcome can disappoint a group, they are stakeholders, whether or not they want to be. Second, take action to minimize the number of decisions that are made under uncertainty. Of course, you seldom have perfect knowledge prior to making choices but how can you narrow the divide?
Bridging the gap—How do I get started?
Most projects begin with an initiation phase. This phase identifies stakeholders, draws up a project charter to identify goals and objectives, details the funding source and amount, lists the project team and sponsor and includes project milestones and deliverables. All these decisions are encapsulated into a project charter.
Unfortunately, most projects train staff after the initiation phase, which is after the important decisions documented in the project charter have been made. You want to train your key people before you make irrevocable choices, priorto initiation. During project initiation, companies start talking to vendors about the tools they can purchase that will help them implement an ITIL solution. You must develop in-house expertise before you begin talking to vendors to be on an even footing. At a minimum, stakeholders and team members should attend an ITIL Foundations class.
Even if you don’t plan to engage a vendor, early training allows your project team to develop a shared vocabulary that permits them to quickly and accurately discuss how to implement the framework. A frequent lament of project teams is "we didn’t know what we didn’t know." Avoid this with early training.
Four key expectation challenges with ITIL projects
To succeed, all project teams must manage expectations—ITIL projects are no different in that regard. The biggest expectation you have to manage in an ITIL project is the assumption that you can manage it as you manage all other projects. Here are four differences that should inform your decision making process during your project chartering sessions and throughout the project life cycle.
1. Your ITIL project will span years.
Consequently, it is crucial for you to scope each project’s goals within your enterprise’s ITIL vision in such a way that each delivers value apart from the whole. For example, when you implement Configuration Management processes, you define a Configuration Management Database (CMDB) to store information on all your configuration items (CIs). To provide value within a single project cycle, you must prioritize your effort to implement the most important CI types first. Choosing those CI types can cause conflict. You can reach consensus by creating an implementation timeline that provides people with a clear idea of when their particular CI type will be added to the CMDB. Your stakeholders may not like being 20th on the list but they’re more likely to support the project knowing that they have not been ignored or forgotten. Remember, the common training experience lets everyone negotiate on equal footing.
2. You should manage the collection of ITIL projects as a program.
Most companies, contemplating an ITIL implementation, have developed a methodology to execute projects. Fewer companies have mechanisms for managing groups of related projects over multiple years.
Given that ITIL implementations span years and projects typically have shorter durations, you may want to create a team that exists beyond the lifespan of an individual project—a program group. The program group's responsibility is to ensure continuity of vision during the course of the entire implementation and to arbitrate conflicts between projects run in parallel.
Extending the previous CMDB example, you may notice that we described the CMDB as an accurate, up-to-date repository of CI information. But that repository doesn't exist in a vacuum. It requires Change Management processes to update the data (project #1). After the data is in place, it can begin to be used by Incident Management to improve service call responses (project #2). Problem Management can collate incident tickets into problems tickets (project #3). A fully developed set of relationships between CIs (project #4) improves impact analysis for planning changes that in turn increases application availability and reduces unplanned downtime. It's the role of the program group to oversee these individual projects. If you don't have such a group, you should advocate for one.
3. You're implementing a framework not a product.
In general, products are easier to implement than frameworks because most major software vendors have honed their installation process over multiple companies. However, when you go to implement the ITIL framework, you’re suddenly faced with decisions about how to fit your existing processing model into the ITIL worldview. Given that your existing processes are embedded inside existing applications, you will be challenged to wire them together.
Don’t expect to find a single best answer. You must use your training to articulate the tradeoffs of different approaches and the limits of the tools you might employ to automate ITIL-based processes. But perhaps most importantly, you must move stakeholders to commit to their decisions. Because ITIL doesn’t tell people to work in just one way, people may want to hold their options open as long as possible. If you find yourself in this situation, remind your stakeholders that each project is just a step in a long journey. You may revisit a decision in a future phase.
4. You will lose resources over the program’s lifespan.
One of the most frequent project plan assumptions/risks I see in project review sessions is assuming the continuity of money, time, and people required to complete the project. Depending on the duration of your individual projects, you may be able to count on the same people being available from the project’s beginning until its end. However, I doubt everyone present at your ITIL program’s initiation will be with you years from now.
If you agree, you should build safeguards into your program to manage the transition between staff members—even senior members. Two mitigation strategies come to mind: First, identify someone as a backup for as many project positions as possible. You don’t have to create a formal position but work to ensure that more than one person understands the critical elements of your individual projects. Obviously, up-to-date documentation and status reports help but you need to avoid sending a single individual to training classes if possible. If your budget limits you to training a single person, plan on transferring that knowledge to other team members. Two, create a training plan that quickly incorporates new project team members into your projects. There is nothing worse than being the new person on a team and not having a structured way to come up to speed quickly.
Managing an ITIL program is different from managing other projects. If you do the things outlined in this article, at the end of the day, everyone gets exactly what they expect.