Method_5of5: project (management)

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:

  1. crisis (resolution)
  2. contract (negotiation)
  3. confidentiality (monitoring)
  4. service (management)
  5. 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 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.


Yesterday I gave a more or less simple and clear definition of what is, in my experience, a service.

While the OGC definitions respectively for project and programme are simple, straightforward, and highly laudable, my experience first as a project team member in the 1980s, then as a project manager and/or coordinator or negotiator from 1990 is slightly less black-and-white.

Whenever I was allowed to negotiate the project from the budget on, I followed the guidelines listed above- on a fixed-price project, the budget derives from the other elements (business case, products to deliver, resources, time, etc).

And it should not be treated (as it happens in many negotiations) as an independent variable.

If I was called in as a project manager, usually one or more of the elements wasn’t as it should be- budget, resources, business case being the obvious candidates.

Why? Because I was too expensive, but I accepted to work part-time (I usually asked to know what the project was about, read the documentation, and then said if, with the time that I was allowed to spend on the project, it was feasible)- if everything had been a clockwork, I would not have been called, and they would have used cheaper internal resources.

I think that I was never called to manage a project full-time: sometimes due to budget reasons, sometimes because somebody else was nominally the project manager- and for plenty of other reasons (the only full-time projects that I managed were for my employers and some of those that I negotiated).

But this is almost a digression- as this outline is focused on managing a “normal” project.

Before the outline, I should present first a small sample taxonomy of unusual projects and project organizations that I found across my career since 1980s, and then show the customary 10-points list.

Why a “taxonomy of unusual projects”?

Because you can find plenty of material on how to manage projects that go well- but almost nothing about managing projects that are less than perfect to start with, or on who to steer back the activities on course (most books are written by practictioners- and nobody enjoys writing books sharing failures and recovery).

Time permitting, I plan to publish an extended taxonomy and management/recovery guidelines (of course, based on my direct and indirect, i.e. observed, experience) in the second half of October.

In the “position” section I will discuss the various shapes that the role of project manager and project leader can assume (yes, a project manager should be a shape-shifter).

And now, my 10 steps to managing a project end-to-end

  1. set the boundaries call it scope, context, business case- it should be a standard, but it is important that you keep monitoring what happens on the boundaries of your project- the longer it runs, the higher the risk that something will change, something that could affect the deployment of the results (software, organizational change, etc) of your project
  2. identify the whole final status it is not just what you will release- but also the existance of the pre-conditions for its use; formally, this is often part of a service setup, but profiling the delivery environment would ease the identification (and management) of the stakeholders that could influence the completion and acceptance of your project
  3. plan an outline backward also when a project isn’t built on a fixed price/fixed time approach, I usually try to do something more than plan- plan and identify the degrees of freedom within the project, associating to each one a “flag”, to allow identifying alternative scenarios to be followed should something happen: an “early warning system” that transcends the milestones, and extends to what could affect the project
  4. structure delivery it comes from my experience in DSS, but I applied this approach in every project: beside delivering the final results, you need to keep the motivation alive in those supporting the project or who would receive its results, to improve their cooperation should the need to introduce changes arise- find something to deliver to give a sense of progression, also if it is just a meeting to discuss with them alternatives, and then showing the inclusion of some feed-back in your plan
  5. keep monitoring criticalities what is critical on a project? Stakeholders, but also the team members’ morale and cooperation, as for the sake of efficiency you will probably have a limited number of people covering all the skills required; and this in addition to the usual technicalities (e.g. using the CPM to plan, identifying the milestones, etc)
  6. don’ t build a bubble the more complex the project, the more critical the time element, and the higher the temptation to build a bubble, isolating the project from the environment; instead, you need to build a unity of intent, so that each team member that, for project-related reasons, need to contact a third party communicates in a coherent way
  7. watchout boundaries and communicationit is part of the previous point (I lost count of how many times I had to recover projects and relationships damaged by gossip or well-intentioned but misleading statements from uninformed members), but it is really the responsibility of the project manager to take on the overall external perception of the project
  8. prepare phase in if you are building a one-room apartment, probably your project can be released in a single “big bang”; but also when nominally the big bang approach was chosen, managing the integration of whatever was the result of the project required preparing key users/sponsors through workshops, brainstorming, panels, or just plain support, so that they could sell their role in the successful delivery- and help you manage expectations
  9. transition and dismantleif a project is a temporary organization, transitioning requires the gradual release of the team members after you ensure the knowledge transfer to whoever would take charge of the project results; in way too many projects I saw team members pulled off without considering the needs for the transition (but any project manager has witnessed the “band-wagon effect”: everybody tries to get on the project when is not needed but the budget is available, and disappears when needed but with just budget residuals available)
  10. share the lessons learned each team member leaving a project should be interviewed- and after closing the project a post-mortem should be produced, to both share the lessons learned, and identify potential critical issues that should have been, for example, vetted while defining the team or the budget; and keep the discussions confidential- your aims should be collecting the information and sharing the lessons to improve the overall efficiency and efficacy of the organizations involved, not shooting the messenger or covering your own back

Resist the consultants’ temptation to skip the lesson learning phase (it is boring, potentially not really that pleasant), and assume that the lessons are embedded into the results.

Each combination of environment, team, stakeholders will produce a unique configuration- reproducing the same results will require the interaction between all these elements, and extracting the lessons learned will help improve the overall efficiency of the new project, while ensuring its efficacy.


As I discussed at the beginning of the “outline” section, I will discuss eventually in other articles how to manage unusual projects- and, therefore, how to coach project managers and project/team leaders able to work under imperfect conditions: coping with risk.

I had often to be both a project manager and a team leader, also if I was working part-time on multiple projects at the same time.

The team leader should have kept the team together and focused on the delivery thanks to her/his knowledge of the business, technical, environmental issues involved in producing the required results.

But, in most projects, I had a “flat” organization (mainly due to budget constraints), and I covered also the business and team motivation/cohesion side (using a combination of GSM and e-mail when I wasn’t physically on-site).

As a project manager I was anyway responsible for the coordination of the “political” (stakeholders management, communication) and economic aspects of the project.

creating project leaders

Usually, for part-time projects, I identified and coached a team member as a kind of “team reference” (more than a team leader), acting as my eyes and ears on the project whenever I was away.

In larger or diffused teams (even virtual, if some members or subgroups were in different locations), I identified “clusters”, and a “cluster reference”, adopting the same approach.

Then, when I was on the project site, I had quick, often informal, brainstormings with each “reference”.

My approach was based on a brainstorming starting with a focus on a specific issue, and completed by a debriefing to identify how a certain status was produced, and feeding to the “reference” the “leads” that helped in proposing the next steps.

Eventually, the “reference” was able to propose how to evolve the allocation of resources or activities without any need of my hints.

I considered a personal success when a “reference” felt confident enough to actually challenge what I said, and proposed an alternative solution based on experience- a kind of informal “graduation” from being a “reference”, to assuming a leading role on the team.

Actually- also in teams where I was able to identify a team leader (usually covering also a specific role, e.g. in software as the architect or lead business analyst), being present but not full-time was a significant advantage, as I was able to observe beyond the details.

Moreover, I had a certain degree of freedom in managing negotiations or discussing with the customers’ hierarchy informally potential issues that had been presented in the brainstorming session (or in previous communication via conference call/GSM) by the team leader, e.g. by preparing the customer to potential delays or budget revisions, discussing together how to manage the communication, and identifying potential alternative scenarios that did not affect what was a “conditio sine qua non” for the customer (budget, time, etc- but not all of them!)

creating project managers

In my experience, you can create a project leader out of a team, as her/his leadership is based on the specific expertise and experience that (s)he contributes, but the shift to project management requires focused training and coaching- and, unfortunately, I saw often project managers who had been promoted without ever receiving coaching or training.

Even worse: sometimes they had been dumped into “management training” courses full of “do this and don’t do that”, without any experience to actually understand how to adapt a standard solution/approach to a specific environment- and under the stress generated by their managers’ assumption that attending a training was enough to convert a team member into a manager.

How did they cope? They tried to emulate the examples that they had found in their own career.

But, as in most other cases of emulation, they were struggling to replicate the results, not the decision making patterns (that they would have received via coaching, if any had been given).

I was able to convert experts into project/relationship managers by giving them test activities with a business purpose (i.e. live activities), acting as a de facto “invisible safety net”, and then using extensively brainstorming, coaching-via-meeting-and-joint-planning, etc, to help them develop a “priority-based” mindset, while helping them to improve their risk management approach.

For example, when I had to coach new project managers for a partner, I identified with him activities outside their usual projects, so that they would be able to learn how to work when you have to manage priorities across multiple audiences and activities.

On risk management, there is a significant issue: a project leader, coming from line activities, is naturally focused on risk removal- whatever the cost.

A project manager, having to consider the larger picture, has to accept a certain degree of risk and manage by priority and potential impact: yes, it is the 80/20 rule.

If you want, it is the old joke: a perfect bullet would cost more than an imperfect one, but both would produce the same result when hunting a wolf.

And risk management brings the last point on project management: what I called in the introduction “emerging services”.

spotting “emerging services” or “spawned projects”

In some projects, when the schedule allowed a relaxing pace (e.g. a 1- or 2-years long project), eventually somebody was tempted to give or ask to do something that wasn’t part of the original project deliverables- why not, almost zero cost.

And this habit was even more common when a project had some “skidding”: delays, part of the business cases or requirements that became not feasible, and so on.

The issue wasn’t finding the “slack” needed to free the resources required to produce the addition result.

The issue was that, as if by magic, often these extemporaneous requests became a routine- e.g. an “ad hoc” report became a monthly report.

And, of course, a monthly report became a statistic.

And a statistic required an year-to-year comparison…

Eventually, this could become a service, as others could ask the same results.

I heard funny horror stories when I was delivering DSS/EIS, methodology, and business intelligence services- in various languages.

If prepare the budget for a project with a link to its deliverables and activities, and keep managing in the same way during the project, you can identify any unexpected request, and isolate a new budget line, also if it means just shifting a minimal part of the budget.

When this budget line keeps being fed with new activities, you can see a potential “emerging service” or “spawned project” before it spins out of control.

In most cases of “spawned projects” or “emerging services”, there was a simple reason why they were allowed to grow beyond control before it was too late to stop the activities (they had been taken for granted by the stakeholders).

Which simple reason? Each project has usually a “contingency”, what in other fields is called “the fog of war”.

You define a perfect budget with imperfect knowledge, as each project is, in the end, a unique blend of known and unknown factors.

Most project managers add a “below the bottom line” contingency, and the use it as a “resource pool” (a kind of project-based “pork barreling”).

I prefer to spread the contingency on budget lines- the slack has to be associated to the specific risk of each activity, not as a “lump sum”.

It requires a little bit more work (I introduced few times this budgeting approach- the last time, a customer saw the process and asked to use it as a pilot for a Clarity project).

But, with limited coaching and limited use of tools, it allows to monitor not only the budget residuals, but also the speed, velocity, acceleration/deceleration in the use of resources by budget line, and be able to pre-emptively communicate/negotiate.

If the team leader does her/his job correctly, as a project manager you can spot and identify potential trends and discuss them with your counterpart on the customer side, instead of mumbling excuses when it happens.


One thought on “Method_5of5: project (management)

  1. Pingback: On methodologies – from Method/1 to Agile | GettingAroundTheWorld.Net

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s