Just Human, Would Do

Project managers must move beyond methodology and focus upon the often neglected and hardest part of project management - the people

In the masterful 1953 trilogy More Than Human, Theodore Sturgeon writes about a bunch of mostly very young misfits, all handicapped one way or another, who band together to become something new, mystical and unbelievably powerful. Society's rejects, incapable of functioning on their own, these disabled misfits "blesh" (a word invented by Sturgeon combining blend and mesh) into a Gestalt: a single, integrated whole. One of them explains: "The I is all of us."

As the publisher's blurb puts it: "Separately, they are talented freaks. Together they compose a single organism that may represent the next step in evolution, and the final chapter in the history of the human race."

Don't you wish your project teams could do that? Wouldn't it be great if you could find a way to get all your "talented freaks" to "blesh"?

"IT projects are about blending the minds of a team," noted Cutter Consortium senior consultant Michael Mah earlier this year in an article called "Complexity Rising Tide". "In this model, it's possible that 1+1+1+1 doesn't equal four. It might be six or eight if you get the blending right, and discover how to make real magic happen."

Today's executives face no greater challenge than that of being a global company with geographically dispersed teams, dealing with the rising complexity of technology projects while under higher pressure from ever-tighter deadlines. In this environment, a blending of the minds in project teams is vital - especially since the things you are innovating today are harder than the things you tried to innovate yesterday. Yet mind-blending is very communication intensive, and "It is a lot harder to blend minds that live, eat and sleep on different continents", Mah noted.

Yet if Sturgeon's characters become something greater than the sum of their parts, many project teams have a kind of reverse alchemy at work. Project team members - all highly competent individuals - find themselves diminished by the chemistry of the teams they serve on. Far from reading each other's thoughts, they misunderstand, miscommunicate, scapegoat, politic and all too often, quarrel. Their leaders pair them with the totally clueless, or vital work falls through the cracks as each uses another's inactivity as an excuse for stalling. They do not so much "blesh" as "squlash" (a new word one could make up: a combination of squabble and clash - hey, if Sturgeon could do it . . .). No wonder so many projects fail.

It has become a cliche to call people a project's most important asset and to say that any project's success depends on the calibre of those working on it. Yet it seems a notion more honoured in the breach than the observance. Enraptured with technique, project managers immerse themselves in approaches to selecting projects, detailing project progress and estimating costs. So now many thought leaders and academics suspect a major link missing from the project management armoury is a focus on the humanity of the human beings that ultimately have to work together for a project to succeed.

Page Break

Madness in the Method

Project managers (PMs) rarely have extensive experience with people management, points out Dimension Data group executive: services Scott Petty. Worse, they are even more rarely assessed on their abilities as people managers.

"Typically they're running a team just for the length of that project. It's rare that they're going to be managing those people after that; it's rare that they're actually the original manager anyway - people are typically seconded into a project. So the project manager doesn't traditionally have great experience with people management skills. They typically have more skills with project management methodologies and how to get those projects done," Petty says.

Inexperienced project managers will find little to help them in the Project Management Body of Knowledge (PMBOK, developed by the Project Management Institute). As RNC Global Projects managing director Diane Dromgold points out, the PMBOK revolves around the project. There is scant instruction on how to get people to do the things that need to be done when they have to be done to achieve a planned outcome.

"Management is talking about the end and we as PMs are talking about the process. I sometimes wonder if we are even in the same conversation, the disconnect is so large," she says. "Every management textbook ever written has insisted on the centrality of getting people to work together. Yet when one tries to find where the textbooks spell out how to make that happen, typically the information is missing or so sketchy as to be unhelpful."

Dromgold points out all the nine core competencies of project management within PMBOK address project internals - they do not address how to make a project work. As a direct result, management has evolved into project administration. We know how to plan, schedule, resource, track and report in repeating cycles but we have not yet mastered the bit about actually getting the outcome, Dromgold says. The bottom line is that if a CIO bets his or her career on standard project management to deliver a complex, mission-critical, visible project, then they are "crazy-brave".

Dromgold says on the whole project managers in the project world and in IT have forgotten that the project is there to deliver an outcome for the business. What they deliver is a process, with even some project managers wrongly believing that the guaranteed route to a good outcome is a good process.

"Projects are used by organizations as a means to achieve something," Dromgold says. "The science of project management is about administration, and execution is largely ignored. In my humble opinion it is no wonder projects keep failing. We've worked out how to manage failure. We've lost the plot as project managers. We've forgotten how to execute. The answer is making sure that every single person knows what they have to do, when they have to do it, who they are depending on, who's depending on them, and what the consequences are of not doing it. It's as simple as that."

Of course even that on its own is unlikely to be sufficient. Cutter Fellow and project management guru Tom DeMarco sees the very phrase body of knowledge as misleading, implying the problems of project management are much more tractable than they really are. In DeMarco's view what distinguishes the good project manager from the bad is talent, not knowledge. "It's not [an issue of] what is missing from the PMBOK, it's that becoming a good manager is not a knowledge acquisition problem," he says.

To say good project managers are born, not made, is to tell a big part of the truth, he says. People can become adequate project managers by learning, but learning alone will never produce a great project manager. "Great project managers are born the way great people are born, in that they have the right personality. I don't think knowledge is enough because when all is said and done, the most knowledgeable project managers are not the best project managers. And becoming a more knowledgeable project manager doesn't contribute appreciably to your ability to manage projects.

"So I think the presumption that there is a 'body of knowledge' for project management is a little bit flawed. The body of knowledge is full of things pertaining to life cycle and procedure, and you certainly would be hampered as a project manager if you didn't know some of those things, but on the other hand it would not be fatal. I mean, people would look out for you and make sure you didn't make mechanical errors."

Moreover, DeMarco says there are gaping holes in the PMBOK because it only provides a formula for the formulaic parts of the project.

"The body of knowledge doesn't touch on any of the things that are most important," he says. "I'll give you an example. How do you decide to assign a piece of work to person A rather than person B, or to make one person a team leader rather than some other person? Those are bread-and-butter decisions you make in managing, and the body of knowledge doesn't speak to them at all, as if they didn't exist. It dodges all the hard questions and offers simplistic answers to the easy questions that any idiot could figure out a workable answer to," DeMarco says.

Page Break

Check the Technique

Davidson Frame, in his 2003 book Managing Projects in Organizations: How to Make the Best Use of Time, Techniques, and People, argues there is good reason for a preoccupation with technique: It is readily teachable. But he too warns that this focus on technique distorts our view of what happens on projects. After all, projects seldom fail because people do not know how to employ advanced project scheduling and budgeting techniques, he says. Rather, they come unglued thanks to unrealistic deadlines imposed by top management, or because project staff lack necessary skills, or because lack of leadership led to aimlessness in project implementation.

Worse, an over-reliance on a stepwise methodology can be dangerous. In fact Bruce Webster, principal at US-based Bruce F Webster & Associates, fears that some organizations have adopted a kind of "cargo cult" mentality about project methodology. There are plenty of tools and procedures for project administration, but too few organizations recognize that these can only help detect problems and failure, not ensure success. So everyone sits around and "worships" the various diagrams without realizing the gulf between the map and the territory or between the methodology deliverables and the working software, he says.

There is in fact no shortage of books on how to get people to do the things that need to be done, Webster notes. On his shelves alone are Peopleware by DeMarco and Lister, Constantine on Peopleware by Larry Constantine, On Becoming a Technical Leader by Gerry Weinberg, The Journey of the Software Professional by Luke Hohman, and numerous others. Yet most IT project managers have never read these books and do not understand the principles involved, Webster believes. And even where they have, there is a big gap between theory and practice.

Webster should know. He was thrust into the position of project manager 15 years ago, and says he "struggled horribly", both because he did not have the team-leading skills he needed and also because he was trying to serve as chief architect at the same time. "While I grew into it and developed many of those skills, though not without some struggles along the way, I received help from two different sources," he says. "First, I had some critical help from several of the developers. Second, about 18 months into the project, we hired a VP of engineering who had excellent project management and personnel skills."

Webster says one key problem is that the project manager is typically either a developer who has been promoted out of hands-on development into project management, as if one set of skills translates into the other (it doesn't, he says, speaking from personal experience), or a manager with no real IT background or team-leading skills. As such the newly inducted project manager can do the charts and graphs but cannot actually lead and motivate the development team, nor verify the truthfulness of developer's claims.

Just as typically, roles and responsibilities are neither clearly defined nor signed off, and many people drafted to project teams still have functional responsibilities, with implications for stakeholder management, says project management consultant Lizz Robb.

"When we look at projects - we've worked in a major pharmaceutical group, working across global sites - the people involved often had functional work to do as well. So what would get done would depend on where the rewards were coming from," she says. Where a person's performance bonus was based on functional work, which was clearly sponsored by the business, that sponsored work would inevitably get done ahead of the project work, she says.

Yet while awareness of the weakness in project management is growing, so far there is little evidence of things getting much better. In CIO's State of the CIO survey 2006, CIOs said they spent almost half their time leading projects. Project management was the number one skill set they believed they would need from new hires, while the biggest barrier to their effectiveness was an overwhelming backlog of requests or projects. Yet project management improvement came only fifth of their top five technology priorities for 2006, behind integrating systems and processes, strategic planning and alignment, external customer service and relationship management, and lowering costs/meeting budgets. And asked their top five IT management priorities for 2006, improving project management discipline did not even make the list, coming only ninth on a long list.

Page Break

The Scars to Prove It

Knowing how to manage projects involves more than understanding the academia of project management; it is about becoming a "hardened, weathered operator". There are some skills that you just cannot teach, says Tony Clasquin, CIO for Wealth Management at Commonwealth Bank of Australia (CBA).

Clasquin likens having good project management instincts to acquiring peripheral vision. When a young child is crossing the road, its parents hammer the message: "Look right, look left, look right again" because the child's peripheral vision has not yet kicked in, whereas adults can see dangers well in advance. Clasquin thinks the PMBOK provides a stepwise process (the "look right, look left, look right" of project management) for the many whose project management "peripheral vision" has not yet developed.

Experienced project managers grow their knowledge by encountering failures and by looking into the eyes of people around the room and asking whether they really understand what they are doing. After all, a project only gets there because of people, Clasquin says.

However, project managers must also learn to distinguish between "being right" and "doing right", he says. To explain, Clasquin uses another analogy. In Australia the law says you must walk, not run, across a zebra crossing, so that motorists have time to stop for you. To walk is to "be right". If you found yourself in the middle of a crossing and a big truck came careering around the corner and was bearing down on you, you would have options: you could stay where you are, continue walking and die legally, or illegally run for your life.

"That's the difference between 'being right' and 'doing right'," Clasquin says. "If you run for your life, yes, you have broken the law, but you've actually got a desired outcome. You're alive and you have helped the driver have a very, very awkward time with the police.

"Likewise in project management I see people say: 'I have e-mailed that person to do [a task] but he still didn't do it'. While e-mailing that person may be 'being right', it certainly isn't 'doing right', which would mean making sure the job gets done. If the person doesn't consume instruction by e-mail, he might respond better to a friendly chat or a phone call. Perhaps his boss needs to give him a push. Either way, 'doing right' involves finding a way to ensure he gets the job done."

Beaten Into Submission

Another problem arises when project sponsors, rather than using project management tools to reach agreement with the project leader, use the tools to batter him or her into compliance.

It is a more common phenomenon that you might think, according to David Maxfield, director of research, VitalSmarts. Maxfield's company and The Concours Group teamed up to conduct a global study of more than 10,000 projects. The researchers were trying to work out why between 70 and 80 percent of projects fall short of their goals or fail outright. Six different Fortune 500 firms worked with the two organizations in focus groups and interviews, while participants from 30 worldwide firms completed a detailed survey.

The study, Silence Fails: The Five Crucial Conversations for Flawless Execution identifies what's missing by focusing on five specific categories of conversations — conversations that are so important, that when even one of them fails, a silent crisis ensues producing failure 85 percent of the time. "When these conversations succeed, the failure rate is reduced by 50 to 70 percent," Maxfield says.

"One project manager said: 'Well, I tried to push back and my sponsor pencil-whipped me into submission. We've got all these project management tools, but instead of using the project management tools to help us all understand and come to a common agreement, they used the project management tools to beat me into submission until I just gave up and said: 'Okay, I will just try and do what you want'."

Maxfield claims up to 80 percent of projects experience this problem, but while 25 percent of project managers dissent, only 18 percent are able to confront the issue effectively. The other 7 percent said they tried to take issue with the approach, but ended up being "thrown out" by their sponsors. And in about 75 percent of projects, the problem continues for the life of the project and beyond. Improving project management performance involves improving conversations between members and stakeholders, he says.

Dimension Data's Petty says another way to lift the project management game is to maintain the links between project team members and their performance measurement system and original manager. "In managing you have almost got, if you like, a perishable resource, so you don't push them as hard as you possibly can until they break," he says.

And if Terra Firma project manager Ignacio Inchausti has any doubts as a project manager about the performance of any team members he will always make contingency arrangements. That can mean increasing the rated risk of the project. "There is no point fooling me and no point fooling the stakeholders or the clients. People are increasingly having to deliver more with less and that places a high premium on risk mitigation."

Inchausti believes it is not only possible, but essential, to capture that political savvy in a knowledge warehouse. Capturing lessons learned is part of the discipline, he says. Whenever his team initiates a new project or starts working on one that has been greenlighted, he immediately turns to similar projects from the past to evaluate estimating experiences and lessons learned.

Page Break

Alert, Aware, Involved

To manage the assignment of people to project roles, RNC's Dromgold has developed her own methodology, "Magia", which provides for visibility of people across and between projects to give management clarity about exactly where effort is being applied. Magia also ensures each person is aware of who they are dependent on and who is depending on them, and which people are over-committed (not just on time allocation but on tasks that require conflicting skills).

Clasquin meanwhile uses a roles-based approach, breaking the entire life cycle down into roles, each clearly spelled out, then assigning people to take on those roles. "One person can take on three roles, but they're now crystal clear what they're supposed to do and what they're not supposed to do, but also crystal clear what everybody else is doing. That means all these awkward transitions go away, all these mishandles disappear," he says.

However, project management is also full of "artificial dependencies", Clasquin argues. That is, people waiting for someone else to act before moving on their part of the project. Eliminating these dependencies means instilling a culture that expects people to consider other actions they can take to further the project while they wait. "There are always, if you think about it for half a minute, other things you can do to progress."

Clasquin says he has successfully instilled such a culture by modelling: getting project managers to constantly question and cajole, continually prompting people to consider other work they could do while they wait, and reinforcing the message at every opportunity that the "hold-up" does not translate to "tools-down".

People management is so important to HigherGround managing director Marcus Batten that unless any project he reviews is organized in clear responsibilities he will recommend it be shut down.

Batten learned his approach to managing projects running a diving operation involving hundreds of divers and 30 or 40 ships in the military in the early 1980s. It turned out the best way to assign tasks to people was to use butcher's paper and a chalkboard, and to type clear instructions for every team member. He says an acronym, RAISV, best spells out the vital principles: Responsible, Accountable, Influencer, Service provider and power of Veto.

"With RAISV you only have one person responsible, two accountable. You can have any number of influencers, and the same for service providers, but they have to follow a rule: If they can't do something for you, they have to give you an alternative or an option. And then power of veto has to be with someone senior to the guy who's responsible who can without reason turn the project off if they want to," he says.

Batten went in to rescue a massive ERP project in the heavy engineering industry a few years back where he found "people basically walking around in circles; they didn't have a clue what to do". He says he spent a week-and-a-half rewriting the project plan in a way that put the people in the left-hand column and all their tasks on the right side, instead of the other way round. "There was this sort of audible sigh of relief that at last all they had to do was read from left to right, which they were good at, and work out what they had to do when," Batten says.

He says the exercise was invaluable in winnowing out problems people had been long aware of but until then had little incentive to mention. "So we flipped the whole focus," he says. "Project plans are built and easy to manage by the project manager but they are nothing to do with the people who actually have to do the work."

In the rock music documentary Anthem to Beauty, Grateful Dead bass player Phil Lesh, referring to Theodore Sturgeon's invented concept of bleshing, describes how the band, after many years of playing together, came to feel like a single organism. "As a matter of fact, I still feel that I'm a finger on a hand," he says.

For many IT project teams a better analogy might be the proverbial herd of cats. Recently in Australia one consultant sent in to rescue a failing project was shocked when two project team members, meeting face to face for the first time after months of communicating by e-mail, discovered to their mutual amazement that they worked down the corridor from each other.

It would be fantastic if we could get IT project teams to blesh, but even a recognition that project teams are full of human beings who need to be managed would be a healthy start.

Page Break

SIDEBAR: The Ten Commandments of Project Management

By James Kerr

In our increasingly project-centric world, the productivity to be gained by good project management is far too promising to ignore. But for most companies, shifting to a project-oriented management structure represents great change, and people resist change, regardless of the benefits that it may bring. Rules and guidelines are needed, so I've devised these commandments. By following them, your company can position itself to enter the promised land of project-based culture.

I Thou Shalt Narrow Project Scope

Nothing is worse than the never-ending project. It can suck up resources and exhaust even the most resilient teams. To keep projects tight and focused, carve larger efforts into smaller projects that have achievable deliverables and can meet deadlines. In the long run, a series of small wins has more impact on the organization than a big bang that never sounds.

II Thou Shalt Not Suffer a Fat Team

The best way to get off to a good start is to ensure that the project team is the right size. Larger teams are more difficult to motivate and manage, and personalities can get in the way of the work. There is no optimum team size, though a good rule of thumb is a role for every person and a person for every role. But if team members need to play more than one role, that's OK. If you err, err on the side of a smaller team.

III Thou Shalt Require Full-Time Business Participation

To ensure that the desired results are delivered, the business perspective must be represented on a full-time basis. Moreover, if business leaders want the best and brightest from IT working on their initiatives, they need to provide the same from the business side. By committing full-time resources to every project, business leaders confirm that project work is important.

IV Thou Shalt Establish Project Review Panels

A project review panel is a project team's governing body, addressing issues of business policy and strategic direction while assisting in the removal and avoidance of project roadblocks and pitfalls. Typically, midlevel business and IT managers from the involved areas participate in biweekly project status meetings. To ensure flow and continuity, any problems identified during these meetings are assigned to project-review panellists, who address them while the project team carries on with its work.

V Thou Shalt Not Provoke Burnout

It's not unusual for project staff to become both mentally and physically exhausted by the stress and struggle of the work. Be sensitive to this and take precautions to avoid it. One common contributor to burnout is serial project assignments. Organizations tend to assign the "usual suspects" to every high-visibility initiative. If you find that certain people come off one project only to be assigned immediately to another, you may want to consider creating some policies that limit or monitor such staff use.

VI Thou Shalt Seek Outside Assistance as Needed

Using outside project experts is another way to prevent burnout. Besides augmenting project teams, outsiders can often provide valuable new ideas, perspective and energy. It's essential to bring the right consulting support into a project at the right time. Specialized technical or business expertise is one type of support; project management expertise is another. Be sure to consider where a given project team is in both its project plan and overall experience curve before deciding on a specific type of external resource.

VII Thou Shalt Empower Project Teams

Project teams struggling to meet deadlines should not be expected to perform pro forma activities such as filing time sheets or attending departmental status meetings. Rather, they should be empowered to do whatever it takes to get a superior job completed on time and within budget. People will work harder in a trusting environment where expectations are well understood and individual initiative is valued.

VIII Thou Shalt Use Project Management Tools

Mundane project management work can be automated. Look for tools that offer project tracking, task management, workflow administration and resource-analysis support on an intranet-based platform that promotes information-sharing and communication. But remember, using technologies that add another layer of complexity to an already challenging project is not a good idea.

IX Thou Shalt Reward Success

All project participants should be recognized in some positive way for their toil and personal sacrifice. The rewards need not be extravagant. Sometimes a sincere letter of commendation from a corporate officer is enough. More significant forms of gratitude such as tickets to ballgames, theatre evenings, extra vacation time and financial bonuses should also be considered if results warrant them.

X Thou Shalt Not Tolerate Quick-and-Dirty Work Efforts

Solid project management policies should obviate the temptation to indulge in quick-and-dirty project work, which only leads to error, waste, rework and frustration.

Kerr is a former CIO and current president of Kerr Consulting Group. Contact him at jkerr@kerr-consulting-group.com

Page Break

SIDEBAR: Yogi Berra, PMP

When a project has you stumped, just think: 'What would Yogi do?'

By Ralph Sacco

If baseball and project management have one thing in common, it's the direct relationship between teamwork and success. Yogi Berra, a baseball legend with a unique approach to management and life, is a particular favourite of mine, so I recently asked myself: What if Yogi were a project manager?

As I thought about it, I realized that Yogi has a lot to say about my line of work. Many of the most famous quotes that have been attributed to him seem to bear directly on the art and science of project management.

PLANNING "You've got to be very careful if you don't know where you're going, because you might not get there."

Have you ever managed a project for which the premise was faulty? If this issue is not resolved during project initiation, you have a major-league problem. It's like when the umpire expects your pitcher to hit a tiny strike zone. Executing to a faulty premise is unpleasant at best and debilitating at worst. Your team can't get traction, and morale inevitably suffers. If the client (or your management) sets unreasonable standards, you have to get out of the dugout and argue balls and strikes. But you need to get your facts straight and communicate with the decision makers in no uncertain terms.

COMMUNICATING "I didn't really say everything I said."

Miscommunication: the gift that keeps on giving. How many times have you held a project meeting and been surprised that it wasn't the "check the box" event you expected? Yogi knew what he was talking about: What I think I say and what you think you hear can be two different things. Who's on first?

DECISION MAKING "If you come to a fork in the road, take it."

Foster a culture of decisiveness and clear execution. I can't think of one thing better for morale, credibility and project effectiveness. This doesn't mean making arbitrary decisions or carving plans in stone. It means putting in the effort with management and team members to make well-thought-out decisions that naturally stand the test of time. And it means weighing the trade-offs in terms of cost, prestige and momentum when facing the possibility of changing decisions that have already been made.

MEASURING PROGRESS "You'd better cut the pizza in four pieces, because I'm not hungry enough to eat six."

Earned value (once calibrated, simulated and adopted) is a very good barometer for justifying course corrections - if you stick with it. But I have been on projects where the management team has tossed out the measures when the news was trending bad. You can slice and reslice the numbers, but it's the same pizza. In the end, you'll still get indigestion.

EXECUTING "Think? How the hell are you gonna think and hit at the same time?

Yogi clearly understands the distinction between planning and execution, and so should you. Once the plan is in place, get out of your team's face and let them do the voodoo that they do so well. I find that during the execution phase, the best approach for me is low-touch - unless things are going very wrong. Try not to tweak things to death. How can your team keep their eyes on the ball if you're constantly yelling instructions from the dugout?

MANAGING "You can observe a lot just by watching. Remember management by walking around, or MBWA? There's no better way to get that all-important gut check on project stats. But remember, there's a difference between chatting it up with the guys in the dugout and second-guessing every fastball.

MEETING DEADLINES "I knew I was going to take the wrong train, so I left early."

Have you ever been on a project where no tasks were completed late? Me, neither. It's a fact that some tasks are going to be late. But there's something you can do about it. While not appropriate for every project, one option is to make it a "project theme" to be early whenever you can. For example, you can authorize some overtime for key tasks from the start. Build up a lead from the get-go even though you aren't behind (yet). This way, you can move things along and reduce your overall risk, especially when you get on the wrong train later on.

CLOSEOUT "This is like deja vu all over again."

We perform the "lessons learned" project phase for a reason. Yet how may times have we got deep into the next build phase only to realize there are still loose ends - just like the last time? If we don't apply the lessons learned, did we really learn them? You've heard the saying that the definition of insanity is doing the same thing over and over again and expecting a different result. When you watch the game films, pay attention.

Sacco is a project manager at a large East Coast technology company. Contact him at ralph@ralphsacco.com

SIDEBAR: Raising the Barriers

The five crucial conversations identified by the study are the most prevalent and most costly barriers to project success. Silence Fails addresses the cost, culture, and long-term dynamics of each. They are:

1. Fact-Free Planning. A project is set up to fail with deadlines or resource limits that were set with no consideration for reality.

2. AWOL Sponsors. A sponsor doesn't provide leadership, political clout, time, or energy to see a project through to completion.

3. Skirting. People work around the priority-setting process.

4. Project Chicken. Team leaders and members don't admit when there are problems with a project but wait for someone else to speak up first.

5. Team Failures. Team members perpetuate dysfunction when they are unwilling or unable to support the project.