Finding The Right Question

What is your moral compass for navigating corporate life?

Here’s a scenario:  your company is counting on you to profitably deliver an outcome for which your client has agreed to pay a great deal, and upon which your client’s business performance is heavily dependent.  If you perform well, you will be rewarded with a significant promotion.  Your team, and especially the key players who have been working overtime for the last 6 months, have advised that a 2-month delay in the schedule will be necessary.  This will delay the client’s business benefit and will negatively affect the profitability of the contract.

Whose interests are paramount?   To whom do you owe the greatest loyalty:  your client, your company, your people, or yourself?  How do you make that decision?

At any level of management, including the executive levels, and in almost any kind of business, we are tasked to do four things:

• Bring value to our clients or customers
• Bring value to our company
• Bring value to the people we lead and influence
• Bring value to ourselves and our career.

Indeed, what differentiates the role of a manager versus a director versus an entry-level executive versus a senior executive is defined by the scope of responsibilities in each of those four areas. 

And moral dilemmas are defined and created by the potential conflict between two or more of those areas.  In fact, the scenario described above has all four in play.  So what would you do?  More interestingly, how would you decide?

I don’t claim to have all the answers, or even to have always behaved over the course of my career to the highest moral standards.  Here is what I do believe. 

First, you must do your best to decide what is “truth” in any given circumstance.  In the above example, you would need to realistically assess the feasibility of adhering to the original schedule.  Can it be done at all by anyone?  Can it be done by this team?  What will be the human cost, if it is in fact feasible?  What will the business cost be to the client if there is a planned 2-month delay?  What will the business cost be to the client, the company, and the people if there is an unplanned 2-month delay?  I am reminded of a line from the recent movie, “Margin Call” when, as the investment company’s world begins to crumble, and the executive in charge of risk management is recalling a key decision of the previous year, she reflects, “It seemed like the only choice at the time.”  The truth, if it were to be analyzed dispassionately, invariably suggests multiple choices.  

Next, I believe our professional obligations generally should be prioritized in the order of client over company over people over oneself.  Why?  Clients come first because we, as individuals and as enterprises, cannot endure if we do otherwise.  The company comes second, because we have an employment contract to honor, based upon which we are being paid to help the company achieve its goals.  And our people come before us, because we cannot sustain a leadership role if people believe we will put our self interests before theirs.

And finally, no matter which area is given preference in any specific circumstance, it should never be at the total expense of any one of the parties.  Any such decision tends to suggest coercion or bullying, in my experience.  While a “win-win” solution may not be possible in every case, there is almost always a way forward that does not involve totally “throwing under the bus” any one area of interest.

One final point:  I do believe that client interests come first, but if one is confident they will be reasonably addressed, then one can go to the next perspective down the chain, and so forth.  Of course, thinking typically is not as sequential as that – it often is quite iterative.  But the notion of the hierarchy still seems to me like a good approach to navigating the waters. 

So the next time you feel at risk of getting lost in the murky morality of corporate life, I suggest you start with the truth, and then decide whose interests should come in what order, while finding some way to acknowledge all the perspectives.

It won’t make your days simpler, but it might make your nights a lot more restful.

What is the point of reporting project or programme status?

In many organizations, the more visible the status is to higher levels of the organization, the less meaning it has.

Wait...what?

So if an executive wants to know how a portfolio of projects is doing, and which projects might be about to experience challenges, she may be pursuing a lost cause?

Yes.  For two reasons. 

First, many project managers have learned that “yellow light” or “red light” status reports make their lives more difficult with unwanted and generally unhelpful attention.  “Green light” status reports, on the other hand, make it easier to focus on productive work, which may allow one to skate through the challenges and end up with a successful outcome.  Maybe.  Hopefully.

Second, as I have written elsewhere, what gets measured and reported on most status reports is rarely of any use in predicting and articulating the need for helpful and timely intervention.  In many organizations, even if their status reports were accurate, the “yellow light” - and especially the “red light” - reports would be describing train wrecks in progress.  Executive intervention would likely be too late to alter the course of history.

So what is an executive responsible for a portfolio to do?  And what is a project manager navigating a career to do?

The answer in both cases, I contend, is to be a leader of cultural change.  Leading downward, executives need to celebrate and reward those project managers who raise flags and ask for help in a timely fashion.  And leading upward, project managers need to report status on the most important, and leading, indicators of project health, along with their recommendations for corrective action by the appropriate executives.

Without such a culture that clearly values the discussion of timely corrective actions, status reports may be little more than a nuisance to project managers and an empty comfort to portfolio executives.

Not much point to that.

What do ambiguous threats and recovery windows have to do with courageous project management?

The Columbia space shuttle disaster of 2003 provided a particularly poignant example for some work done at the Harvard Business School by Amy C. Edmundson, Michael A. Roberto, and Richard M. J. Bohmer[1].  The loss of the ship and all crew members was found to be the result of a foam strike upon launch.  There had been a twenty-year history of such strikes, although this one appeared to be a particularly large piece that may have been capable of causing structural damage.  Asking the CIA to divert some spy satellites to take pictures of the exterior of the shuttle, and ultimately launching a rescue shuttle, would have been the only decisions that might have altered the course of this particular history.  No one seemed individually prepared to argue strongly for either action.  When the decision was made to wait until after re-entry to complete the examination, the fate of the crew was sealed.

What has this got to do with courageous project management?  The Harvard researchers described two phenomena in decision-making within organizations:  ambiguous threats – risks that may have an outcome that is completely unacceptable – and recovery windows – that period of time beyond which no recovery is possible, regardless of subsequent actions.

Does that sound familiar in the project management world?  Looking back on disasters we have been close to, wasn’t it obvious that success was unobtainable unless the poor estimate, inadequate team skills, lack of key sponsorship, or whatever other critical factor was in play had been addressed early and quickly?

I have written before on the topic of courage for project managers.  Let me explore one aspect of the dynamics at play – the apparent powerlessness that project managers face. 

Typically, executives are placing direct or indirect coercive pressure on project managers to “just do it”.  And yet, I believe that it is the project manager with a track record of successful delivery who holds the real power.  Imagine the response if any of us were to stand up and say, “I cannot be successful unless we take the following actions within this specific time frame.  If that can’t happen, you need to find a project manager who you believe can do it.  I am not that person.”  I believe that nine times out of ten, the executives will respond as we need them to, because they know in their fat little hearts that we are right.  In the case of the other one time, we don’t want to be anywhere near the pending disaster anyway.

Acting courageously is easier when you know you’re right and you know you have power.  As you think about your next project, evaluate the ambiguous threats, determine the recovery window for corrective actions, and know that you are the power player in altering the course of this project’s history.

---

[1] “Facing ambiguous threats”  Roberto, Michael A; Bohmer, Richard M J; Edmundson, Amy C
Harvard Business Review November 2006 pp106,108-113

What are the most important things to measure, track, and manage in projects and programmes?

Interesting question, but it first requires some insight into what “important” is.

Let me suggest two dimensions of “important”:

1.    The degree of impact something has on our ability to deliver a great outcome, and

2.    Whether our assessment of that factor gives us a leading or a lagging indication of success.

Great.  We now can look at this topic through the lens of a classic two-by-two matrix, like this:

  

And we might conclude that the answer to our big question should lie in the upper right quadrant, and secondarily perhaps in the lower right quadrant.

Or are we spending most of our energy on measuring, tracking, and managing other things?  Well, let’s see…

Elsewhere I have written about seven key factors in project and programme success.  Briefly, they are:

• Stakeholders are committed
• Business benefits will be realized
• Work and schedule are predictable
• Scope is realistic and managed
• Team is high performing
• Technical risks are mitigated
• Delivery organization benefits will be realized.

In my view, and especially as our projects and programmes are played for higher and higher stakes, three of those factors are of supreme importance to success:

• Stakeholder commitment
• Business benefits
• High performing team.

Furthermore, of the seven factors, only two can truly be assessed in a leading indicator fashion:

• Stakeholder commitment, and
• Business benefits.

All others present lagging indications, to a greater or lesser degree.  That is, by the time enough time has elapsed to give a reliable read out, it can be difficult to “correctably” manage to a highly successful outcome.

So by this analysis, our two-by-two matrix looks like this:

        

Yet what do we measure, track, and manage mostly?  Things, I suggest, in the lower left quadrant, especially:

• Work & Schedule (although really only if we are doing some sort of Earned Value Analysis) and
• Delivery Organization Benefits (and only to the extent of understanding the financial costs of delivery versus the promise).

 

 

***   Wait…what???   ***

 

 

So we only measure two of the seven factors, and those two are not the most critical, and in any case, are lagging indicators?

Yikes!!!!

Now, a word about measurement, because I can hear you protesting that it’s awfully hard to quantify Stakeholder Commitment, for one example.

It is possible, and frequently beneficial, to measure without significant precision.  We do it all the time.

If you are driving in winter and are coming to a curve, you “measure” the road conditions to determine if the surface is ice-covered or bare.  You don’t need to know the specific coefficient of friction between your tires and the road surface to decide whether you need to slow down.  And yet the road condition is your leading indicator for successful navigation of the curve.

 

*   *   *   *   *

 

So back to our matrix, and our big question.

As a programme or project manager, where are you going to “up your game” in measuring, tracking, and managing for a successful outcome? 

What does that look like?

And who do you look like, as a leader, not just a manager?

 

Good questions….

What is the difference between a project manager and a program leader?

That would beg the question of what the difference is between a project and a program (or programme, as many of my international colleagues would spell it). 

Programs, unlike projects, are, by intention, transformational.  As a consequence, here are some characteristics of programs that are different from projects:

• The stakeholder landscape includes Board level and cross-functional senior executives
• The nature of a program is often a “bet the company” strategic effort
• The specific work plan is not knowable at the beginning of the journey
• Expanding value delivered is more critical than controlling scope
• The performance of a team of hundreds (not dozens) needs inspirational (not controlling) styles of leadership
• The solutions that leverage such significant business value have many potential failure points
• The organizations responsible for delivery (internal IT, software vendors, consultancies) must also adopt a “bet the company” level of commitment.

(Some of you may have noticed that the previous seven bullet points seem curiously correlated to my view of the dimensions of project/program health.  No coincidence there.)

So how does that translate into the differences in our personal “game” as we move from project manager to program leader?  Here is my view of the critical areas that require a transformation in our own competencies:

• Executive level relationship management – we must become trusted advisors to a wide variety of senior stakeholders
• Leadership and personal power – we must achieve through influence and coaching, not through command and control
• Understanding and delivering business value – we must gain a deep understanding of the business problem, and ensure that all aspects of the program are driving to optimize business value
• Articulating a vision – it is our ability to inspire that will keep everyone moving toward the goal, in spite of fears, anxieties, and confusions that are inherent in programs
• Masterful negotiating skills – we must be able to craft a win-win situation among the many (and often competing) internal and external organizational objectives.

Sound a bit daunting?  Here is the good news:  I believe that effective program leaders are made, not born.  That is to say, one can learn and acquire proficiency in the competencies I have listed above. 

Mind you, these competencies do not come easily or quickly, but there are approaches that will accelerate these aspects of professional development for the program leaders of tomorrow.

The investment of time and money required seems appropriate if you’re going to “bet the company” on the competency of a program leader.

Why don’t good methods prevent project planning failures?

Is there now some scientific thinking to suggest method development is a fool’s errand? 

In his recent book, “Streetlights and Shadows;  Searching for the Keys To Adaptive Decision Making”, Gary Klein makes an interesting case.  He presents a number of arguments, with many disparate real world examples, to show that the more complex the situation, and the more extensively documented the procedure (such as most IT development and implementation methods!), the less likely a competent professional will use it, and the more likely that an inexperienced person will perform at a mediocre level at best.

Let’s run that by one more time.  If the target audience for an IT method is experienced project managers, they probably won’t use it…  And if the project manager is inexperienced and the project is a complex one, we are pretty sure that’s a recipe for disaster…

Hmmm…

Maybe we need to re-think this a bit.

Historically, project managers have railed at methodologists for not understanding the complexities of project life.  (There is an old joke that asks, “What’s the difference between a methodologist and a terrorist?  Answer:  “You can sometimes negotiate with a terrorist.”) 

So when the project manager asks the methodologist, “What’s the shortest time that this type of project can be done, with acceptable quality, under the following circumstances?”  The answer often sounds like, “I can’t tell you, but you better have these 1200 line items in your work breakdown structure.”

Why are we surprised, then, that good methods do not appear to prevent project planning failures?  Indeed, my experience suggests that most project managers rarely reference method materials, but they almost always reference work plans from trusted sources (and sometimes the only source they trust is themselves). 

And the corollary might be:  why are we surprised when “bad” methods (like the seductive siren song of Rapid Application Development or Agile Development) are adopted with almost religious fervor and mis-applied in complex and mission-critical situations?

So what’s the answer?  Well, if we can’t get methodologists to adequately address the real world of project management, why don’t we educate project managers to have a better understanding of methodology?

I am not arguing that project managers re-invent a method for every project (although many like to do that).  I am saying we might limit the prescription of methods to, say, 25 tasks (5 life cycle phases with 5 tasks each, perhaps) and then teach project managers to build plans that answer my two favorite questions:

          1.       How will we know when we are done? 

          2.       How will we know we have a good solution, not just any solution?

This, of course, will necessitate extra effort and intelligence at the planning stages of complex projects.

Oh, right, that could be a good thing…

In these difficult economic times, where can I cut corners in my project (and still succeed)?

In the classic three-element formula for projects, you can play with any two of scope, time, and resources.  If you are trying to reduce resources (for economic reasons), and your world will not let you take forever to finish, then you must reduce scope.  How do you figure out the minimum levels that will still lead to success?

 

Here are some thoughts to guide those decisions, based upon the dimensions of project health known as the Seven Keys To Success.  If a contemplated reduction in scope would jeopardize one or more of these dimensions of project health, then in my view cutting corners in that fashion would be ill-advised.

 

And there are two fundamentally different ways to cut scope:

 

Reduction of features and functions

 

This can be a highly successful way to reduce costs (and also speed up the schedule, and perhaps even reduce risk).  The health dimension to monitor is Business Benefits Will Be Realized.  If the contemplated reductions will not too adversely impact the business case (and the reductions can be added to a later version, perhaps) then cutting corners this way can make a lot of sense.  One caution:  the judge of this should be the business sponsor, not the Project Manager or the IT function.

 

Cut tasks in the methodology or radically reduce their level of effort 

 

This is the second, and potentially more insidious, approach to reducing scope.  Remember that a methodology is supposed to provide a reliable answer to my two favorite questions: “How will we know when we are done?” and “How will we know if we have a good answer/outcome, not just any answer/outcome?”  (On these two questions hang all the methods, the controls, and the quality.)

 

So what might we be tempted to cut? 

 

IT history is replete with ideas like “Rapid Application Development” and “Agile Development”, often followed by lots of project failures, because practitioners of these approaches tried to cut too many corners in the early stages of understanding requirements.  You can’t reliably manage the twin health dimensions of Business Benefits Will Be Realized and Work And Schedule Are Predictable if you follow a flawed method. 

 

Here’s another temptation:  let’s cut all the “soft” activities like communications, change management, and perhaps even training.   After all, they don’t contribute directly to the production of a working solution.  Perhaps they are unnecessary.  Perhaps, if you have fewer stakeholders/users than you have programmers.  Perhaps, if there is no apprehension among anyone about how their world might change.  Perhaps, if the new functionality is so trivial and obvious that anyone will come up to speed instantly. 

 

The first and most critical dimension of project health is Stakeholders Are Committed.  And project managers cannot merely wish this to be the case.  Even the Business Sponsor (the most important stakeholder) cannot dictate a healthy level of commitment from all the other stakeholders.  It does in fact take some communications, some change management activities, and some training.  Be very careful about what corners get cut here.

 

The bottom line

 

Cutting corners judiciously can help us get through these tough times.  Just be sure that you don’t sacrifice good health and success for the sake of (apparent) expediency.

What Is So Hard About Getting Governance Right In IT Projects?

Maybe just one word:  responsibility.  Or more specifically, the fact that s/he didn’t take the appropriate level of responsibility.

 

So we reduce it to an after-the-fact blame game:

• The Business Sponsor was missing in action (didn’t take responsibility for the business benefits)
• The IT Department didn’t understand the business needs (assumed responsibility that wasn’t theirs)
• The Project Manager didn’t blow the whistle in time (can’t be responsible for everything, but certainly is responsible for knowing when things aren’t healthy)
• The Contractor took the money and didn’t meet deadlines or satisfy the user (we paid them a bunch of money, so they must be ultimately responsible, mustn’t they?).

 

These common (and often justified) complaints are firstly symptoms of flawed governance, and not fundamentally of individual incompetence or bad behavior.

 

So let’s start with the First Law of Project Governance:  There must be a proper, and properly functioning, Steering Committee:

• “Proper” means that it is chaired by the Executive whom the organization will be holding accountable for the promised business benefits and costs.  Its members are other executives who lead organizations that will be impacted.  One of those will be the IT organization, who must advise on the technical aspects of total cost of ownership, technical risks, and so on.  The bigger the business impact, and the more cross-functional the operational changes will be, the higher in the organizational food chain that Business Sponsor must be.  Almost never is it appropriate for the CIO to chair the Steering Committee.  Unless the cost and impact is so small and so contained to the IT shop that the top executive wouldn’t know or care if it failed.
• “Properly functioning” means that the Steering Committee meets at least once a month (and a minimum of six times in the life of the project).  These meetings must have an agenda designed to illuminate major project issues that require decisions and actions from members of the Steering Committee.  The Chair of the Steering Committee must be present and engaged.  The Project Manager must own the agenda for raising critical issues and recommending a course of action.  He or she must also report back on results and timeframes from previous decisions.

 

So what’s so hard about that?

 

Well, it takes time and focus for the right people to be doing the right things in a Steering Committee.  Sometimes they legitimately don’t have the time to spend, and/or other matters are consuming their focus.

 

When this is the case, serious consideration should be given to cancelling or postponing the project.  Or better yet, redesigning the project scope to have a big enough impact to support the right behavior.

 

If we fail to recognize this problem early, we are almost certainly going to be playing the blame game later.

If you could invent a video game called Project Management, what would it be like?

Here’s my version.  Imagine this:

 

You, the Project Manager, are at the wheel of a race car traveling at high speed over open ground.  Off in the distance is a wall stretching as far as you can see from left to right, but in the middle of the wall is a hole about twice the width of your car.  The challenge is simple.  Steer through the hole and you win the prize, and the faster you get there, the bigger the prize.  Miss the hole, and you smash into the wall – no prize, no more fast car, no more driver.

 

So what’s the catch?  Well, obviously crosswinds, bumps, loose suspension, and other factors tend to take you off course.  All that’s fair game.  What makes this challenge difficult are the following two limitations you must learn to deal with. 

 

First, your steering wheel only turns five degrees left or right – you better be making a lot of small corrections early or you will get yourself to a point where you no longer have room and time to correct. 

 

Second, you can’t turn that wheel by yourself – you have a partner in the car with you, your Executive Sponsor, and you only get to make steering corrections if he or she agrees to help.  So you better be good at communicating with that Sponsor about when steering corrections are required and why. 

 

Does this metaphor for managing projects sound too simple?  Of course it is.  But I think it’s instructive, for three reasons:

1.    You must partner with your Executive Sponsor in order to take corrective actions.

2.    All projects, including successful ones, require lots of corrective actions. 

3.    This isn’t as simple as steering one car toward one hole in the wall.  You have to manage (or steer) seven different kinds of vehicles simultaneously if you want to grab that prize and avoid crashes.  That is, I believe there are seven dimensions of project health you need to be continuously monitoring.

 

Do you have the instrumentation to detect distance from center line (and rate of change), distance from “the wall” (and rate of change), and whether enough time remains for a five degree correction to take effect? 

 

If not, you’re driving blind, wondering when your screen will say, “Game Over!”

How Can We Learn To Be Courageous Project Leaders?

There is a saying in the field of Change Management about people being averse to change.  “The pain of status quo has to be greater than the pain of change.”

Here’s a new one for Project Managers.  “The fear of remaining silent has to be greater than the fear of speaking up.”

And what are the situations that test our courage?  How about:

• A key team member with uniquely valuable skills is being a jerk;
• A client/business executive is undermining the team’s success; or
• Your boss is asking you to perform miracles.

I believe that project life sometimes presents you with only two choices:  do you want to make a career decision now, or do you want to make one later, but you are going to make a career decision.  I also believe that those of us who have developed any kind of a reputation for delivery under adversity have much more power and credibility than we typically credit ourselves. 

Bosses want us to help them see the world through rose-colored glasses.  And some of them are pretty good at applying coercive pressure to get us to agree with them, when we know in our fat little hearts that the situation is deeply troubled.

Yet we often stay silent, and pay the price.   Why?  Because we fear for our jobs?  But if we fail to deliver, aren’t our jobs just as much, if not more, in jeopardy?  Not to mention our mental and emotional health...

How can we learn a different behavior?

By remembering our experiences, and those of our colleagues.  We must remind ourselves that the fear of remaining silent should be greater than the fear of speaking up.