Method_Considerations on resource management

Last week I posted online a series of articles, on various management issues- Crisis, Contract, Confidentiality, service, project.

The title of the series? “Method_” something (search for “Method_” on the front page of this blog).

As many articles on this blog, this series was part of the draft material prepared for a publication with a larger scope, called, you guess, “the method” (BTW it is a concept that I registered in the USA; see the “signpost” online here).

Look at my cv: in alphabetical order, I was involved in the audit/coordination/definition/facilitation/management of accounts, activities, budgets, campaigns, negotiations, portfolios (of applications, projects, products, services), products, programmes, projects, services, startups, units, websites (and probably something else- but let’s just keep to the most common keywords).

One of the sections was to be devoted to resource management, and, within resource management, project and service management..

A not-so-small digression

The choice of the lowercase “s” and “p” in “service” and “project” was by design: while a crisis, contract, confidentiality should be considered as having potentially strategic impacts, services and project usually are operational issues.

I know that this definition will ruffle some feathers- but, frankly, be honest.

However long a project, it is usually “framed” by a contract, and it is in the best of the cases a self-contained universe (that’s what the CE in PRINCE2 stands for- controlled environment).

The same applies to service management: you have (should have) an agreement defining the boundaries of the service delivered, and corresponding agreements to ensure that you can deliver the service.

Yes, it is a controlled universe; but no, it is never self-contained: you have customers interacting with the service, and potentially other suppliers up the feeding chain, e.g. those providing what is needed to deliver your service, or those involved in helping solve unexpected issues.

A breach of customer information confidentiality could affect the long-term business perspective- and the costs to repair the damage on the market positioning of the affected business is disproportionate to the actual cost usually involved in generating (by accident or design) the damage.

As for a contract or a crisis- well, mismanaging in these cases could irrevocably damage the confidence in the business or organization.

But, in this article, I would like to share an outline of the conclusions, by presenting the draft of a segment planned to be both a preamble and a conclusion to the section- do not worry: I will just outline the ideas.

If you want, skip directly to individual ideas

Idea 1: “but we are different”
Idea 2: “who are you working for?”
Idea 3: “the phase-in/-out of project managers”
Idea 4: “the atomic theory of resource management”
Idea 5: “efficiency as a unit, efficacy as a structure”

Idea 1: “but we are different”

I will give you a practical example: in the late 1990s, there was a shortage of IT people- everybody was working on Y2K and adapting to the Euro.

It became common for companies to “snatch” their competitors’ employees, by offering nothing more than a marginal increase.

With a logic that defies gravity, my contacts and partners said- yes, but we are different.

And were disappointed when some shrewd employee kept jumping ship within their “trial” period- as they had done before.

I already had seen what happened when people were given “pre-emptive bonuses” to deliver something on time- they got used to the approach, and they always expected an increase larger than the last one.

No matter how profitable your activity is- you cannot manage loyalty by using an inflationary approach: the increase will be taken for granted, and any increase should have to “feel” an increase, e.g. getting 8% on 100 is an increase of 8, and getting 7.5% on 108 is 8.1

But people would feel under-appreciated, and they expect at least 8%, if not more.

If you don’t believe this- I tried to make some of my colleagues wake up to reality, that they had had a monetary increase, when they complained about what they were receiving.

I am talking about the late 1990s- but I should say that I observed the same issue in late 2000s, albeit on completely different technologies.

In IT, it is cyclical- like in fashion, sometimes a technology becomes “trendy” (or, more down-to-Earth, a new regulation requires to do something within X months): and the few possessing the skill… reap the benefits πŸ™‚

Over the last two years, I had the “opportunity” to study the job market- and I saw the same pattern in some postings online (as recently as this week).

How do you spot it? Simple- when you see a description that pin-points to a specific combination of skills and experience- as it could be delivered only from somebody working in the same market- but for a competitor)

Maybe because somebody assumes that the time that they will stay on board will be enough to recover the investment, and, also if they were to jump ship at the earliest opportunity, it would take some time for the competitor to embed into operations the knowledge that they will carry along, enough time make it irrelevant.

In some industries, it could actually be beneficial- it is a way to share experience across a whole industry- with on-the-job training, instead of having people attend training courses πŸ˜€

to the table of contents

Idea 2: “who are you working for?”

The first time that I heard variations of this phrase was when I was still working for Andersen on Comshare DSS products, and then, time and again, while discussing with other customers the hiring of people to cover senior positions.

Actually, the one saying it was always somebody high enough in the company (a controller, CIO, CFO, marketing director, etc), and always referring to the same issue.

Their concern was that it seemed as if people coming from companies with a strong internal cultural identity (or “brainwashed”, as they said) kept their loyalty toward their first employer, and not their current one.

Once I was working with a customer as a consultant, with no plans whatsoever from either of us to change the business relationship, as my skills were needed only short-term.

The customer said that sometimes hiring people like me coming from “gated communities” felt like hiring a fifth column for their first employers- as they kept referring to them as potential suppliers.

But there is a grain of truth, and comes not from misplaced loyalties, but from something more basic: the cost of “vetting” a supplier, i.e. evaluating if the supplier is really able to deliver.

Years later, I was working on a project, and I discovered that one of the contacts on another project was a former Andersen manager I worked with in the past, but I had been told that he had left in less than friendly terms (no, he wasn’t fired- he left).

Nonetheless, he kept considering them as a potential supplier.

His rationale? Better the devil that you know, that the devil that you don’t.

By knowing what to look for, it was easier for him to negotiate a contract with them, and look for the tell-tale signs that could have generated issues- he had better control.

Frankly- it is not just Andersen (anyway, it does not exist anymore- Accenture is a different company), but any large consulting company.

Whatever side-effect of their activity, they need, to survive their own size, to build a series of “behavioural patterns”, and therefore they become predictable.

I remember reading a piece of advice in a book on photography that I studied when I was a teenager (it was pre-digital): what matters is getting a developing and printing that is reliable and with a constant quality, as some labs could then produce stellar quality once in a while, but you cannot rely on “good days”- you do not want that unique shot to be wasted by a “bad day at the lab”.

Predictability can be a quality- also in business.

to the table of contents

Idea 3: “the phase-in/-out of project managers”

In the 1990s, it became common to negotiate fixed-price projects (and services).

I would not say which, where, when (confidentiality)- but I observed and discussed (and was also part of) few “blood baths”, as some colleagues defined their projects.

Actually, in last decade, on some projects I was more than once the second or third project manager involved in the activities (also as a facilitator/negotiator- or whatever you want to call it).

The concept was really simple: yes, everybody wanted a “fixed price”.

Purpose? Both the supplier and the customer knew what they were going to do, and at which price.

Of course- you would need perfect knowledge to produce a perfect budget that results in a perfect plan that is perfectly executed with no changes whatsoever.

And a perfect environment- what some consulting companies try to achieve by building a “bubble” within their customers’ environment.

Well, I do not know your religious inclinations- but usually this “perfect knowledge” is not considered a human quality.

And we are ordinary people with imperfect knowledge.

If you have time, watch the movie/documentary/interview called “The Fog of War”, with Robert McNamara- also if you do not give a damn about war or international politics, some of the lessons are a XX century transposition of the much read (also in business, unfortunately) and not so well understood “The Art Of War”, or “Machiavelli”, or “The Wealth of The Nations”.

Why XX century? Because with WWII, we increased speed and distance- and re-invented logistics and how, where, when you produce.

The telegraph globalized the world of finance during the XIX century (albeit it took 50 years to have a world-wide network), the airplane and container-based logistics globalized the physical world (in half that time).

I first studied the logic of containers for a DSS project in late 1980s, as I had never worked in logistics before- it was funny to learn about pallets, containers, and how standardization allowed to move faster without really caring at each step “what” you were transporting.

You moved Lego bricks- and Lego bricks are the same worldwide.

And, with something that will come handy in the (Idea 4), with a controller I designed an optimization model reducing complexity to what they used- a single parameter: Kg/L/Km (i.e. how many liras did cost to shift one Kg by one Km).

Military history has a nice side-effect: give few years, and there are so many people dissecting any event under so many perspectives, that you can get the “lessons learned” with more transparency than you would ever obtain from an individual business case story.

Imperfect knowledge can wreak havoc when you are shuttling millions of tons of materials around the world.

There was a funny song/poem (I think published on an internal US Army magazine such as Stars and Stripes in WWII) that told the story of the “catchup” between the troops… and their supplies.

Such as knowing that your summer government issued – GI – clothing is few hundred miles ahead of you, and probably you will reach it… by December.

On a smaller scale, this happens also in fixed price projects: you lack the information to do a perfect plan, and you factor in some “fog of war”.

The problem is: once the project starts, often everybody works by the plan, or considers the plan as a general guideline- almost always “tertium non datur” (i.e. nobody considers alternatives).

You just need to drop in few unexpected changes to see under which approach you are operating.

In both cases, you have to cope with reality, always intruding with your blueprint.

How do you cope- generates ripple-effects.

A delay. A change of sequencing of the activities. The sudden unavailability of somebody who was planned for day X, but is already scheduled elsewhere on day Y, when he is really needed.

And so on, and so forth.

Some project managers simply get overwhelmed- or are just plainly unlucky, as sometimes nobody would dare to say that there wasn’t enough information to prepare a plan, and that a preliminary phase (or a different approach) was needed.

What happens? You replace the first project manager with a second one, negotiate a rescheduling with the customer, and, if you are lucky, the second project manager is able to steer the ship.

I mean: if you are lucky enough to have had the first project manager fell on his own sword and reveal all the missing information, maybe also proposing what should be done to put everything in order.

But if the first project manager tries to save his own face… the second one is needed to make all the issues surface.

Then, it becomes the usual “shooting the messenger”, and the third one comes through- having a clear visibility on what is needed.

The subject is, as usual, matching reality with plans- if you know that you are planning under the veil of ignorance, there are approaches (agile, iterative, etc) that allow to deliver a transparent re-adjustment.

to the table of contents

Idea 4: “the atomic theory of resource management”

No, I am not referring to nuclear bombs or power stations- but to the etymology of the word “atomos“- indivisible.

Strange things happens when you mix somebody with a passion for physics, first activities in budgeting, controlling, financial data consolidation, management accounting with some variation on logistics (optimization, planning), marketing, production planning (MRP, BoM), and other “let’s simplify complexity” approaches while still in the early 20s.

If you ever worked with me, you know that I am naturally inclined to identify patterns embedded into reality.

Why? Because this allows to then choose two alternatives: it is a repeatable pattern, or it is a unique, once-only pattern.

To make our life simpler, for the rest of the discussion I will refer to the first as a “service”, the second as a “project”.

But also services have often to adapt to change due to the interaction with other services, suppliers, customers- before you can apply your pre-defined, standard patterns.

If you read the articles in the “Method_” series, you saw the standard definition:

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.

There is nothing in the definition that constrains the size of the organization (albeit there are practical limits, if you want to apply the standard processes from PRINCE2/2005, and even PRINCE2/2009).

I will get straight to the point- the discussion will be presented if and when I will have time to publish the full material.

When you identify what is unique, you can identify its context: is it worth doing, considering the service or project you are working on?

Or it exceeds your purpose and/or budget acceptable for such “minutiae” within the scope of your service or project?

And if it makes sense to do it, what is the most efficient way, within the framework of the main activity (be it a service or a project)?

We started with a service- and we ended up with what looks like the definition of a project- less the complexity of project management.

By adopting this approach, you can also pre-emptively identify what is inconsistent with the purpose (e.g. “una tantum” activities within a service environment).

Or decide to delegate the specific execution/production not to the most obvious candidate (the team involved in the main service or project), but to a different team.

This will allow to keep the original team on track and ready to get back the results of the new activity when ready.

The key issue? Identifying the “atomic” elements within your context- maybe they could be further divided into component activities or products.

But, from the perspective of the main activity (service or project) their internal subdivisions are not adding any information to your own needs for their presence.

to the table of contents

Idea 5: “efficiency as a unit, efficacy as a structure”

Also if you did not read all the articles posted last week, if you managed at least to read the previous sections of this article, you can probably appreciate more my position.

As I said in the introduction, I worked on various forms of structured and/or organized activities (the two do not necessarily go hand-in-hand, albeit often it is assumed so).

No matter how you call it, the issue is to ensure that each component part delivers with appropriate efficiency its results, so that the overall structure can deliver what it needs to deliver (“efficacy”).

What is puzzling is that, by splitting methodologies in tribes, the first goes sometimes against the second- i.e. you are highly efficient in doing something, but ignoring its overall impact- or raison d’Γͺtre (raison to exist).

As I wrote in other articles, I believe that it is correct to have “specialized corps” of project managers, portfolio managers, programme managers, risk managers.

Albeit a product or service portfolio is not to be managed as a project portfolio- products are, in my view, to be managed as a service, if you want to deliver repeatable efficiency.

Look at the order: I consider projects to have a lesser degree of uncertainty than portfolios, which in turn have a lower uncertainty than programmes or risks.

Somebody could say that risk is transversal: and I am more than inclined to agree.

Personally- from my experience and observation of dozens of companies, both in change management and in activities related to technology and business intelligence, I derived a really simple approach (that I applied when coaching project and relationship/service managers).

I think that basic risk management and basic project management skills (see the previous ideas) should be part of the backbone training of anybody aspiring to be coached into a portfolio or programme or corporate risk management position (no matter how small the organization).

The difference is simple (from my standpoint): you can teach theory, but the higher the uncertainty, the higher you need to understand the context in which the theory has to be applied.

And that’s why I am skeptical of portfolio or programme or corporate risk managers who know nothing about the organization they are working for.

It is already often difficult for a project manager to deliver on time and on budget what was agreed.

Because if (s)he does not know the corporate culture (and, consequently, the stakeholders involved), (s)he will omit the appropriate communication.

Or, even worse, keep outside of the loop as irrelevant somebody who could be irrelevant from a quantitative point of view, but highly influential on others who have more direct impact on the project’s success.

to the table of contents


One thought on “Method_Considerations on resource 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