Information Technology Blog

Portfolios and Project Management Organizations (PMOs)

A New Way of Thinking About Organizational Projects

Organization Success: It All Comes Down To Projects

The 5 Habits Of Highly Dysfunctional Companies

Guest — Fri, 08 May 2009 14:37:50 +0000

The concept of management by projects is a non-starter. The average company is not a project-driven company, and likely never will be. So why is this an idea that continues to be so prevalent? What problems — real or perceived — do it's proponents hope to address? And if the project-driven organization cannot exist, what business model will surface that will reasonably address these problems? This series takes an in depth look at these questions, and offers insightful and reasoned answers.

As I previously discussed, project management as practiced in organizations today is heading for a shake-up. Projects are successful today in most instances despite the company, not because of it. But management by projects is not the answer.

Project management will not supplant the existing structures and processes. These frameworks need to evolve, however, if companies are ever to realize their project management goals consistently and reliably. Organizational structures need to recognize project management, but they won't be replaced by it.

As a means of beginning the discussion of what projects will look like once organizations fully embrace the need for consistent and effective project management, let's explore some of the key barriers that exist today:

The budget year. Possibly the single biggest barrier to how company's think about projects today has got to be the arbitrary division of our money into 12 month periods. How many times have we heard that the deadline for the project is December 31, because that's when the money runs out? How many more times are we going to hear it before companies wake up and realize that projects don't have to be managed in 12 month stints? When will the bean counters clue in that just because it makes their jobs easier, that doesn't mean it's in the best interests of the company?
Planning for the budget year. If the budget year is the biggest constraint, how we plan for it is a very large number two with a bullet. Most projects get conceived well in advance of actually being planned and initiated. Fair game; this isn't going to change, because the amount of work we have will always exceed the resources we have to do it. It's what keeps us employed. The first time projects get estimated, however, is during the budget planning cycle, which for most companies represents a time when we haven't got a clue what the project is going to do, let alone how much it will cost or how long it will take. Yet once the initial estimate is established, it becomes an immovable constraint, never to be revised or forgotten. We need to change our approach to the budget cycle so that we understand the project first, or we allow fluidity in the estimates until we actually know what we're trying to do. Or both.
Managing each project to it's overall numbers. In know, I know. On the face of it, this one makes no sense. But think about it. As a company, we invest millions in projects every year. Some projects are over budget, and some are under. We kick the project managers who are over, and praise those who are under and next year we do it again. The reality is, projects are uncertain. Some will come in over their targets. Some will be under. Get a grip. If we spend $10 million every year on 30-odd projects, then manage to the $10 million. If one project needs more, take it from the project that has some to spare. But don't kick the project manager that went over. You still want them to perform on the next one, don't you?
Creating a business case for everything that moves. Don't get me wrong. Business cases are a good thing. As with all good things, however, they are best when taken in moderation. Not all projects should require a business case; some aren't big enough to warrant it and some are too obvious to warrant it. And some projects have no direct benefits, but they're essential to other ones that do. Don't make infrastructure project justify the benefits when it's the strategic projects that use the infrastructure that will deliver the goods. Don't make the first strategic project justify all the benefits of the infrastructure, and give the others that follow a free ride.
Not being sure of what we want the project to really do. It is true that the single greatest reason for project failure is not fully and completely defining the project requirements. It is equally true that many project customers haven't really got a hot clue what they actually want. Projects are born for all sorts of reasons. Some we start, some we inherit, and some were invented in a conference room years ago, where no one's had the grace to put them out of their misery. If you don't know what you want, cannot define the conditions that will determine whether you have it, or how you are going to evaluate whether the having is a good thing, don't let the project start. And if you do, again, don't take it out on the project manager you force to carry the ball in a game you can't define.

There are many more reasons that projects and operationally-driven organizations currently do not play well together. This is just a start. But resolving these few issues would go a long way to dealing with how projects and companies can co-exist more effectively.

Related Posts

A New Way of Thinking About Organizational Projects

Organization Success: It All Comes Down To Projects

The Best Project Management Methodology

Marios Alexandrou — Tue, 05 May 2009 14:24:03 +0000

I received an e-mail from a visitor to my site who described the following situation:

Hope you're fine. I was wondering if you could possibly help me. I'm a final year project management student currently undertaking a university research project as my final year assignment. I was shocked to see that so many methodologies actually exist as we have only been taught Prince2. My question is, what would be an ideal methodology for me to undertake in regards to a university project on children with asthma? My university has received funding from an organization called [company name removed] and we want to create an Expert Patient Program for young children with asthma. This will be done by conducting a number of workshops and drawing conclusions from the children's views. Any ideas?

This sort of question is not all that uncommon. Until you've run a few projects and looked in to different methodologies, it's quite natural to believe that there is a one size fits all process. Unfortunately, there isn't, despite what some vendors would have you believe.

Skill Level and Experience
Your choice of methodology is going to depend a lot on your skills and experience along with the skills and experience of the development team. The last thing you want to do is use one of the modern, agile methodologies with recent graduates that have never worked on a non-academic software project.

Corporate Constraints
Corporate policies may dictate a specific set of steps that can't easily be mapped to all methodologies making the list of options shorter. The pharmaceutical industry is particularly stringent when it comes to documentation. Small startups may have resource limitations that require focusing their efforts on a "good enough" solution to get something out the door as soon as possible.

Team Location
Will the team be offshore? Will they be in house? Some methodologies, with their emphasis on process and documentation, are better suited for projects where interactions between members may be restricted by distance and/or time zones. In house teams, because of constant communication, can sometimes make do with lighter methodologies.

Project Scope
The level of understanding of the finished project will also influence the selection of an appropriate methodology. Looking to simply convert an application from one language to another? A basic waterfall or modified waterfall approach is probably fine. Don't quite know what the end result should be because you're doing something exploratory? Then you better toss out anything that even comes close to looking like the waterfall approach and choose something more agile.

The list of considerations goes on and on, but hopefully the above demonstrates why there is no such thing as the best project management methodology.

Related Posts

The Seeds of Project Failure

Improving Project Management

Surviving a Project Audit

Projects and Investments

Guest — Sat, 02 May 2009 14:05:18 +0000

In a previous post, we discussed the reality that while the practice of project management may continue to advance, overall project results will not significantly improve until better decisions are made through the full lifecycle of an idea. One of the most significant barriers to improvement, however, is the comprehension of what this lifecycle represents in terms of stages — and where the responsibility for decisions resides in each stage.

From the perspective of a project manager, the project starts when they get assigned to it and stops with the completion of whatever it is that they've been tasked with building. Simple and straightforward as far as it goes, but it's also perfectly clear to most readers that there is work that still happens before the project starts and after the project ends. In particular, there is whatever decision making process actually led to the project being initiated and a project manager being appointed, and the later process after a project is done of beginning to use whatever was produced to get the value that the organization desires.

From the perspective of the organization, or of a senior manager, there is therefore a different view of project that starts with idea and ends with realized value. What we have is two very different definitions of project, which have different start and finish points. This is not to say that one definition is right and the other is wrong. Both are important, yet we tend to use the same term of 'project' to describe both. It is the failure to distinguish between these two ideas that leads to enormous misunderstandings in organizations. Not only is it not clear where the project starts or finishes, but there is confusion around who is responsible for what.

To clarify, it helps to separate out for the project manager and for senior management what it is that they are trying to accomplish. The project manager wants to know what they need to get done. The executive wants to get the value out of their investment. Both are necessary. The product that is produced is what allows the value of the investment to be realized. As a result, both are also inextricably intertwined. Yet they represent separate ideas, which means that we need to speak of them and consciously identify them as being different.

To illustrate this distinction, it helps to look at a case study. One example I often use in workshops is an organization that undertook a quality improvement project associated with their billing system. The impetus for the project was a benchmarking study that indicated that there were 5 times as many people in the organization responsible for correcting billing errors than the average for the industry. To bring these numbers in line, the organization initiated a project whose objectives were to reduce billing errors by 95%, which would allow them to redeploy up to 45 people elsewhere in the organization.

The project proceeded forward quite successfully. Tracking their reduction in errors over time, the team eliminated 97% of errors, focusing on the most significant ones first. They delivered on time and under budget. Throughout the project, extensive consultations were made regarding plans to redeploy staff members to more significant, value-added positions. When the project was completed, however, the organization in the middle of intense negotiations with their collective bargaining unit, and chose — in order to avoid a grievance being filed — not to redeploy the staff members. As a result, 50 people were now doing the work of 5, and the organization failed to realize any of the projected savings. It's a sad story, but a true one, and not necessarily out of place in any number of organizations.

When I asked workshop participants whether or not the project was successful, invariably the room was divided along 50-50 lines between those who say 'yes' because the team did what they were supposed to do, and those who say 'no' because the organization failed to realize its investment objectives. Both statements are objectively true, however only one describes project success.

The reality is that the project was successful–more than successful, in fact, in the context of the objectives set for it. Defects were reduced to a greater extent than hoped, and the project delivered under budget. By every objective measure of what the result of the project was to be, the project team delivered. The investment, however, was a failure. Over $1 million of investment was written off, for reasons that had nothing to do with the project. The reason to not redeploy staff was a business choice, made for operational reasons. Not to say that this was a bad decision either — the cost of a grievance could well have been much higher than any projected savings. Yet this was not a project decision, it was an organization decision.

The point here is a simple one — any initiative must be evaluated with respect to both dimensions. Project success evaluates whether or not the process and what was produced as a result of the project — the 'final product' — was successful; in other words, did you get what you had hoped for out of the project, and was it delivered within the allowable envelope of time, cost and resources? Investment success evaluates whether or not you realized value out of getting the final product of the project; in other words, did you get your hoped for return on investment, however that was being measured.

That these concepts get blurred is understandable, but they genuinely define different concepts and therefore must be considered differently. We must objectively understand what the expectations are of both the project success and the investment success. Ideally, we realize both. Where one is realized despite — or at the expense of — the other, it is important to understand the underlying causes. To simply blur the two together, however, is to avoid the need to manage both, and to avoid setting accountability for each where it truly lies.

Related Posts

A Critical Look At Executive Decision Making

A New Way of Thinking About Organizational Projects

The Road To Organizational Change

Guest — Wed, 29 Apr 2009 13:38:20 +0000

The road to organizational change is an odd one: both well traveled and unfamiliar at the same time. The intensity of resistance, the many bumps and potholes and the sense of isolation all too often lead one to surmise that the road is one seldom traveled. It is easy to assume that few have passed this way, and those that have had not too easy a time of it. Certainly no easier than ourselves as we face it today as if for the first time.

The capacity for effective organizational change shares many attributes with common sense: a feeling that it is all too uncommon, and lacking in widespread, rational logic. No subject has had more books written about it, yet still been so widely misunderstood and misapplied. The effectiveness of organizational change approaches appear on the surface to have no formula, pattern or framework for repeated success. Even among the purported and often self-styled 'gurus' there is no one practitioner that has been able to maintain a sustained reputation for success in the field. Movements have come and gone; fads have emerged and with equal rapidity faded into the mists of embarrassing memory. We look on them with the same sense of discomfort as the first time we asked someone we 'really liked' out on a date: awkwardly, sweaty-palmed and with the nagging feeling that success, if attained at all, was fleeting and insubstantial.

No question endures more, has been thought of as much, and has been answered with such variance, as of the role of grassroots participation in creating successful, sustained and meaningful organizational change. Do we dictate, or do we facilitate? Is corporate success attained through the brilliant insight and forceful guidance of a select few, or the participation and widespread consensus and commitment of the many? Is it the responsibility of senior management to direct and mandate, or to influence, facilitate and guide?

To look at the industry is to find no easy answers. In a corporate environment that lionizes the blunt and more than ruthless approach of 'Neutron' Jack Welch and 'Chainsaw' Al Dunlop, you have an equal number of proponents of 'servant' leadership, participative decision making and self-managed teams. Both models argue financial, corporate and market valuation successes. Which begs the question of just who is right?

The answer will not be easy. There are too many proponents, too many myths, and too much misguided, untested, yet devoutly believed philosophy for us to emerge from this argument unscathed. Yet the need for an answer is both palpable and growing in importance. Organizations are at a crossroads, with an uncertain path before them: Do they answer to the market? Their customers? Their board members? Their employees? Their conscience?

At a time where the need is greatest, the answers have gone away. In the late '80s we had Total Quality Management. In Search of Excellence. Strategic planning. Peter Drucker. The '90s launched with re-engineering. Tony Robbins. The 7 Habits. Today, every author wants to launch the next fad. Every consultant wants to be the next guru. Every business leader wants to be on the next Fortune cover. Clarity has been replaced with chaos, obfuscation and greed.

In the absence of a clear path forward, a clear mandate of performance, and a clear mechanism to drive organizational change, we stumble from fad to fad, guru to guru, catchphrase to pithy aphorism. All of which suggests that we seek most is participation, involvement, community and involvement. And yet we remove ourselves further from meaningful commitment, participation and attachment. The social contract has been torn up. The man in the grey flannel suit has been replaced by the corporate free agent.

In future posts, we will focus on the models for organizational change, in an attempt to resolve the conundrum of how to secure effective, meaningful and lasting change an organization - from the top, or from the bottom? By executive fiat, or negotiated consensus? What works, and why?

While a definitive answer may yet prove elusive, we will all be better off for at least asking the question and attempting to establish a reasoned insight into the issues, enablers and stumbling blocks of successful change.

The implications are far reaching. Dissatisfaction has emerged as a general state of being: with ourselves, our spouses and families, our organizations and our governments. While the frustration continues to grow, the answers to how change can be achieved and how the will to initiate the process can be crystallized become increasingly elusive.

Related Posts

The Problems Of Top-Down Leadership

Organization Success: It All Comes Down To Projects

16 Project Manager Traits

Is Project Management a Fad?

Guest — Sun, 26 Apr 2009 13:12:32 +0000

An emerging theme that I have encountered in conversations of late is the perception that project management is becoming the latest management fad. Interestingly, my reaction has ranged from "Is it?" to "Already?" to "Why did it take this long?" For someone who has been on the inside of promoting and developing project management as a corporate competency, it is easy to develop the impression that this is the way things have always been done. Objectively stepping back, however, project management as a formal discipline is a much newer concept for many organizations.

While the principles of formal project management have been around for decades in more 'traditional' industries such as engineering and construction, project management as a means of leading information technology, process management and organizational change projects began to be introduced in the early 1990s. It is only since the late 1990s that from an organizational and senior management perspective, it has begun to take root in many companies.

It is this level of organizational awareness that seems to represent the tipping point that separates a tool, technique or approach from being the passionate focus of a small group of knowledgeable practitioners to a widespread but less understood fad. Looking at many of the management trends that have come before — total quality management, re-engineering, Six Sigma, customer relationship management — they have all followed a very similar path. Like televisions shows 'jumping the shark'(a term coined to define a TV series at the point of decline — immortalized when the Fonz jumped a shark in 'Happy Days'), what was valuable and unique ultimately become bland and without content.

At their outset, each of these approaches represented a viable and theoretically useful means of accomplishing some outcome, whether improving processes, optimizing quality practices or increasing the knowledge of overall customer requirements. Rooted in proven, valid and fairly complex practices, they were able to generate significant gains for the companies that invested in understanding, adopting and adapting them to their specific needs. As they were realized, recognition of these successes by other organizations and promotion of the value of the approaches by other consultants led to additional attempts to replicate the original achievements. The first wave of practitioners with a deep level of understanding of how the techniques were customized effectively were followed by a host of 'me too' consultants who saw an emerging opportunity to market their services. Even more companies attempted to mimic the achievement of the early adopters, but success proved more and more elusive until ultimately the fad was discredited as being meaningless hype.

So was it the practices that failed, or was it the practices becoming fads that led to their demise? To a large extent, the problem is both. Any practice, properly applied, is context specific. Just as every company does not have the same organizational structure, accounting system or HR policies as every other one, neither will the same approach to re-engineering, quality or project management work interchangeable from one organization to another. The early successes were based in large part because a considerable effort was expended in trying to figure out what worked, and what didn't, in the specific context of one organization. Organizations attempting to replicate this success took the techniques that worked for the one and tried to duplicate them in the others, regardless of the appropriateness of context. By definition, some would work and others would not — but the further you moved away from the context on which they were based, the less relevant they were.

The nature of fads, however, certainly hastened the descent of these practices into the dustbin of irrelevance. They are appealing by their nature because they have the promise of being a 'silver bullet'. No matter how often we intellectually recognize there are no silver bullets–just hard work–emotionally, we still cling to the hope that one day we might find one. Once a technique becomes a fad, marketing and hype take over. The motive to adopt an approach becomes less and less about the specific results, and more about emulating what others have done to get their results. What gets adopted is the surface appearance of practices, without the underlying rationale, discipline or context necessary to make them work. What companies are left with is an empty shell. This is a little like buying a sports car with no engine; it looks pretty, but it doesn't go very far.

That project management is starting to be view by some as a fad is therefore more than a little disturbing. Clearly, marketing is taking over — the number of conferences and books on the subject are now growing exponentially. While executive teams are recognizing the need to manage projects better, there is often a subconscious — and occasionally overt — expectation that this shouldn't come at the expense of having to be formal and disciplined about anything. When style takes precedence over substance, the demise of a fad cannot be too far behind.

The lesson for project management — and for any discipline — lies in going back to what worked in the beginning. For the organizations that experienced early success, what drove that success was not simply the practices that they landed on. Far more important was the process of experimentation and discovering what did and didn't work for them, that led to the identification of the tools and techniques they kept. We need to embrace the learning and experimentation that leads to understanding of value and context, not simply borrowing and benchmarking from others without giving thought to how what is being borrowed can — or should — be applied. Project management needs to be adopted because it works for us, not our competition or the company down the road. More importantly, we need to take the time to truly understand how to make it work for us. There are no silver bullets here. But there just might be a silver lining.

A New Way of Thinking About Organizational Projects

The Seeds of Project Failure

Where Should The Responsibility For Project Management Really Lie?

Guest — Thu, 23 Apr 2009 12:31:34 +0000

As we've previously explored, there are a number of operational barriers to project management trying to successfully exist in the majority of today's companies. This month, we explore what organizations might look like once projects and operations do learn to play nicely together in the same sand-box.

Project management today exists in a bizarrely schizophrenic continuum. At one extreme, there is no defined capability for project management whatsoever. Project managers reside within those business units who see sufficient value to pay their salaries, and they are expected to apply their skills and political wiles to repeatedly wrench success from the jaws of an indifferent and uncaring organization. At the opposite, multiple project management offices compete vociferously for the attention and loyalty of project managers and executives alike, each offering the 'one true way' as if project management were some new-age mysticism.

What seems sadly lacking for most organizations today is balance. Contributing in large part to this problem is the absence of a reasonable and identifiable home within the company where project management can hang its hat and get comfortable. If there were a Maslow's hierarchy for management disciplines, it would surely say that before self-actualization is possible, shelter is essential.

In many respects, the quest for a logical spot in the framework of the organization has strong echoes of the struggles that information technology departments had for relevance and support a decade or two ago, and for many of the same reasons. When the value of IT began to assume a level of some importance in the organization, one of the greatest challenges became where to put it. The push and pull between a centralized infrastructure resource and a decentralized operational function generally resolved itself with the IT organization reporting to Corporate Finance. While this satisfied no one greatly, they at least shared the qualities of generally not being very much liked or understood.

Now that the value of project management is beginning to be understood, the same questions of where to put it are coming to the fore. Ironically, many organizations are choosing to shroud a mystery in a conundrum - creating project management as an extension of the same information technology organization that only 10 years ago was itself adrift in the uncharted white space of the organization chart. As with information technology before it, project management will not be relevant, valuable or viable until it clearly defines its role within the company, and carves out a space for itself in the reporting hierarchy. To submerge the project management function within the operational business units is to risk drowning it under the weight of ill-defined demands, or starving it of the financial oxygen it needs to breathe and the visibility it needs to grow. Placing it within the information technology function, however, risks severing project management from its roots within the operational units and grafting it onto a support organization that cannot be given full authority or accountability for business results.

As I have argued previously, organizational success is driven first and foremost by operational performance. While project management creates the enablers that allow operational performance to be improved or maintained, it crosses organizational boundaries and does not properly limit itself to information technology, engineering or the core operations units. It must span and embrace all of them in different measure at different times. The idea that project management should be separate and distinct from core operations is one that should be embraced, not concealed.

The proper role for project management, then, is as a separate unit that can be appropriately scaled up and down with the ebb and flow of the organization's needs. It must be held accountable for project outcomes, but funded based upon future needs rather than current operational performance. It must be able to align with the strategic plan, and have the flexibility to engage any and all operational units as necessary in realizing the company's strategic goals. And it must be answerable to senior management, but focused on the people whose success it is measured by: the operational units that do the real work of the organization every day.

Related Posts

Organization Success: It All Comes Down To Projects

A New Way of Thinking About Organizational Projects

Two Project Management Metaphors

Marios Alexandrou — Mon, 20 Apr 2009 12:19:26 +0000

I recently got through the book, The Blind Men and the Elephant by David Schmaltz. The sub-heading of this book is "mastering project work". That, along with recommendations from others, prompted me to buy the book expecting to read about processes and techniques for managing projects. That's not quite what I got.

The book turned out to be quite philosophical and while there may arguably be actionable items, there certainly wasn't anything resembling a checklist or process description that I could apply the next day at work. Regardless, the book was thought-inspiring which is certainly a good thing. In particular, David described some metaphors to describe projects and project management.

First off is the description of projects as being a battle. A description that David doesn't like in the least.

"Predictable things happen when we start describing our projects as battles. People behave as if they are soldiers. Directions become orders. Work becomes fierce competition. Plans become immutable. Enemies emerge. We and our opponents become less than human, shrinking as individuals. Our Technicolor world fades into opaque wrongs and colorless rights, when our success requires a palette filled with the possibility."

I'm not sure that I've ever treated a project like a battle. However, there have been people connected to my projects that became enemies in my mind. I think that's a natural reaction and not necessarily a bad one. There will always be people that will stand in your way and some of those people will have malicious intent. So, shouldn't they be considered enemies?

The second metaphor David suggests is that of a tree.

"How are projects like trees? Trees are hierarchies branching both up and down from a central trunk. We see the trunk or the canopy and recognize a tree without seeing the part of the sustaining organism working silently below ground."

"Project organizations are hierarchies that seem to branch only down from a central point. But like trees, project organizations are more complex than they appear. When we see a team pursuing an objective, we recognize a project without ever detecting the invisible networks sustaining it. What soil supports this tree's roots? What nourishes it? What sort of photosynthesis sustains it?"

The tree metaphor obviously lacks the negative connotations that the battle metaphor has. It also captures the idea that a project has more going on with it than is readily seen. This last point is one that I wholeheartedly agree with. I've often said that a smoothly running project appears as if no one, project manager included, is expending any effort.

Related Posts

Project Politics

Is Project Management a Fad?

10 Styles of Innovation

Marios Alexandrou — Fri, 17 Apr 2009 12:01:46 +0000

In a recent issue of PM Network, Peter Fretty covered the topic of innovation in corporations. His perspective is that innovation doesn't always arrive with a bang, but that is can also be an incremental process that takes years. Along with his review of these two types of innovation he also provided some guidance on fostering innovation. But what I found most interesting about his article was the innovation styles he referenced.

Overly concerning oneself with labels doesn't accomplish much, but at the same time I think labels can help you understand behaviors that you can make the best of them when you see them in your project team. And with that, I present the 10 styles of innovation.

The Anthropologist
This type of innovator ventures into the field with the intent of observing how they interact with products, services, and experiences. This information provides guidance for innovating.

The Experimenter
Despite the name, this style is all about calculated-risks and involves a lot of test and retesting of potential scenarios to turn ideas in to tangible products and services.

The Cross-Pollinator
This style reminds of the Dell. Dell doesn't create anything new, but they are excellent at taking existing products and adding a layer of value to the equation resulting in the breaking of new ground. This pretty much describes the style of a cross-pollinator.

The Hurdler
A tireless problem-solver who derives motivation out of tackling something that's never been done before without regard to the threat of failure from experts.

The Collaborator
This style values the team over the individual person and prefers to coax people out of their bubbles to form multidisciplinary teams.

The Director
Innovators that possess an acute understanding of the big picture often find themselves motivating their team members to step forward and take a leading role in the creation of something new.

The Experience Architect
What drives this type of person is the need to turn something ordinary into something extraordinary that clearly stands out from the crowd. Not a particularly easy task as you can imagine.

The Set Designer
A real team plater, the set designer builds work environments that celebrate the individual. The upside of these efforts is the stimulation of creativity from the resulting energetic and inspired culture.

The Storyteller
As the name suggests, this style aims to capture the imagination with an irresistible narrative of initiative, hard work, and innovation.

The Caregiver
Like a medical professional, this style aims to understand each individual customer and create a relationship to inspire innovation.

I think of these styles I'm closer to a cross-pollinator than anything else. And if I could, I'd like to be a better at being a storyteller. How about you?

Related Posts

Project Teams

The Problems Of Top-Down Leadership

A New Way of Thinking About Organizational Projects

Project Politics

Portfolios and Project Management Organizations (PMOs)

Guest — Tue, 14 Apr 2009 11:36:36 +0000

To do a project, or not to do a project. That is the question.

The rationale by which project decisions get made varies widely from organization to organization, and is for the vast majority of organizations largely a subjective process. While a few short years ago the linkage between projects and strategy was a much more tenuous one, it is now becoming much more widely recognized that projects are a key means of realizing organizational strategy. The choices we make in terms of the projects that are taken on have a significant influence in defining organizational strategy for the organization.

From the perspective of the PMO, an important consideration here is where and how the process of prioritization occurs in deciding which projects to proceed with. Because prioritization represents the intersection between strategy and one hand and project delivery on the other, a strong case can be made for the PMO managing the prioritization process. This is in fact emerging as one of the key roles that the PMO plays in several organizations I have worked with. Arguably, however, an equally strong argument can be made that prioritization must be managed by the business. Given the growing trend towards the PMO at least playing some role in the prioritization of projects, what emerge as key questions are: a) should this be a role the PMO takes on?; and b) what aspects of the role are most appropriate for the PMO to manage?

The key danger in this role falling to the PMO lies in the fact that a true PMO cannot make decisions on behalf of the business. They can administer the process, facilitate the identification of criteria, and even maintain the records of the decisions that have been made, but they cannot actually make the decisions. What this really reflects is the role of PMO as facilitator, rather than PMO as owner, a theme that has emerged many times in previous columns.
Were the PMO to truly manage the prioritization process, they would in effect be responsible for setting the strategy for the organization, an abdication of the role of the business itself. That said, where many organizations fall down on the business side is on having a process to effectively manage prioritization. Prioritizing and choosing projects all too often devolves into choosing between apples, oranges and kumquats — without a process and objective criteria for prioritization in place, making choices between projects becomes more about a popularity contest than it is about objective decision-making. Looking at executive teams that I have worked with in the past, many have very confidently been able to make effective decisions within the bounds of established evaluation criteria, but have struggled with the wide open question of "what criteria do you need to see demonstrated by a project in order for it to be able to proceed forward?"

What the PMO can do to effectively respond to the challenges described above is to manage the process; to facilitate its definition and use, and to act as a guide in the establishment and application of prioritization criteria. This is a much more strategic role than what many PMOs may do today, but done well represents a significant opportunity for the PMO to be able to add significant value to the project management process — by helping guide the organization in choosing the right projects, the chances for projects to be successful rise exponentially.

To be able to facilitate an organization's prioritization process, there are some fundamental capabilities that the PMO needs to establish or ensure are in place:

A process for prioritization and approval. One of the most significant challenges in project initiation is understanding how a particular project must be prioritized and approved. For some memorable organizations I have observed, even after 12 months I couldn't objectively tell you up front what a process a specific project would need to go through to get approved. Every project was treated differently, with some flying through the approval process in record time and others that were equally if not more valuable being bogged down with committees, reviews, business cases and consultant reports. For any project of a specific type, size and complexity, your organization should have in place clear guidelines that define what needs to be done to get project approval, and who is responsible for granting that approval.
Clear criteria for prioritization and project selection. Over and above understanding the approval process, there is a need to define clear and objective criteria of how projects are to be prioritized. Simply put, prioritization criteria are the qualities or attributes that a project needs to have in order to be able to proceed forward now. It defines what aspects a project must demonstrate and support if it is in fact aligned with the strategic plan. Whether the criteria are strategic alignment, risk, resource availability or financial return, the criteria should be defined, understood and able to be evaluated on a consistent basis from project to project.
An understanding of budget and resource capacity. Prioritization is one thing; the capacity to deliver on your priorities is another. Within any category of projects, there will from year to year be far more projects than there is the financial and resource capacity to deliver those projects. This means understanding the core budget available for projects, and more importantly the resource capacity of the organization to staff them. Resource capacity is particularly challenging simply because so many organizations are lacking the tools to be able to effectively track how much effort is available for project work, and how much of that effort is already committed to initiatives underway.
Commitment to use the process. Finally, the PMO can only facilitate a process where there is willingness and commitment for the PMO to facilitate the process. Where the organizational commitment isn't there, a process cannot be imposed on the organization. Bottom line, the prioritization of projects is still a business choice, and regardless of how tempting it might be, a process cannot be imposed if the business is not prepared to accept a process. More importantly, commitment to use the process must mean that all projects are subjected to the same prioritization process — if a project is allowed to bypass the process that the rest of the opportunities are required to adhere to, the process will no longer be credible and prioritization will revert to gamesmanship.

There is absolutely a role to be played by the PMO in supporting and facilitating the evaluation and prioritization of projects and opportunities. This role, as discussed above, must be as a facilitator rather than a decision maker. As awareness of the role of projects in delivering strategy continues to grow, however, effective facilitation is the capability that most organizations will need most.

A side effect of this role is the increasing move of the PMO to a role of being a corporate capability, rather than being the province of a single business unit or functional area. PMOs that do not report to a corporate level today will find this role much more difficult to take on, simply because their reporting structure can lead to a perception of conflicts of interest being present. Where a corporate mandate and accountability structure already exists, this role becomes more readily accepted. The value that results is better decisions, better projects, and ideally better project results. Isn't that what the PMO is all about?

Related Posts

Tools Aren't Process, But Process Is A Tool

A Critical Look At Executive Decision Making

10 Steps to a Successful Project

Marios Alexandrou — Sat, 11 Apr 2009 11:19:54 +0000

The state of Maine spent $25 million on a web-based Medicaid claims system. In exchange for all that money, they got a $300 million backlog in unprocessed claims. Doesn't seem like a particularly good deal, does it? The details of this web services project were unique, but the problems were quite common. Projects fail all the time and there are often plenty of people to point fingers at.

Stemming from this project's failure, CIO magazine has assembled a list of 10 steps to a successful project. As with such lists, a lot of specifics are glossed over. Still, the list is instrumental for project managers to consider to see if they're similar mistakes.

Scope Out a Detailed Plan
Well that's a new one isn't it? Imagine planning what you're going to do and having a good idea of how you're going to do it before you're too far down the road.
Watch Out for Bad RFP Bids
This is a good one worth noting and brings to mind the old saying of you get what you pay for. If a bid seems unusually low compared to other bids, you might want to find out why. Maybe the firm wants your business enough to take a loss or maybe they just have no clue what they're doing. Another warning sign is an unexpectedly low number of bids. This can indicate that the knowledgeable players want to stay away from the project. Again, you should find out why.
Plan Ahead
Bring in subject matter experts to provide guidance to developers. You'll need these people to describe why things are done one way and not another. Don't leave it up to your technical folks to make the call. Business process expertise is often overlooked and yet the people with this knowledge are often willing to help a project succeed.
Find the Bottleneck
A system can be built only as fast the most complicated component. Sometimes throwing more resources at the problem can help, but other times you need the help of certain people such that it really doesn't matter how many people you have ready to start writing code. Make sure you identify these bottlenecks before you run in to them head-on.
Do Not Cut Corners on Testing
Don't skip pilot tests. Don't forget to do end-to-end testing. While it will feel like a good way to fix schedule overrun, you're actually just delaying and magnifying the project's problems.
Develop a Backup System
As a project manager you'll want to do everything in your power to make the new system a success. However, that doesn't mean you shouldn't have a backup plan. Often, a backup plan is just being able to go back to a legacy system if the new system doesn't work as expected.
Prepare Other Contingency Plans
Having a legacy system that you can fall back on if needed isn't sufficient. You need to communicate your backup plan to system users. They need to know what their options are when things go wrong before things go wrong.
Train, Train, and Train Some More
Make sure your internal staff, including your call center, are adequately prepared to work with the new system. There should be ample documentation and preparation before the switch is flipped. Anything less and the chances that the project will fail increase.
Be Honest
When something goes wrong, be upfront to your staff and users. Avoid making promises that you don't know for sure you'll be able to keep.
Triage Fixes
When problems arise with a newly launched system, it is important to deal with them just like a triage. A triage is defined as a situation where there are more problems (usually medically related) than there are resources to resolve these problems (usually doctors). With a long bug list, you'll need to prioritize the items and tackle the big ones first. Avoid the bells and whistles until the important items are addressed.

Related Posts

Projects and Investments

Surviving a Project Audit

16 Project Manager Traits

The Battle For Control of Project

Guest — Wed, 08 Apr 2009 10:53:49 +0000

In a previous post, we explored the challenges that currently exist in finding an appropriate home for the project management function. In this post, we take that discussion one logical step further, in an attempt to understand just why there is such a conflict between factions over where the project management function belongs, and who does or should retain ownership over it.

For many organizations, particularly where project management is part of a centralized support department like information technology, the battle lines are very clearly and overtly drawn around the issue of control. Enormous turf battles are waged over who controls the projects, as well as who 'owns' the project managers and can therefore direct their activities. I have seen customer business units actually hire their own project managers and provide salary allocations to the IT department, solely so that they can ensure focus and full time attention to their projects.

As with so many inexplicable organizational behaviours, the first question that we need to ask in understanding this situation is 'why?' What has led the organization to such a high level of dysfunction that managers and executives believe they must control the project manager in order to control the project results? Why do otherwise rational and sane individuals believe they need to engage in such extreme political behaviours? And what of the poor project manager stuck in the middle?

Where project management has become established in non-traditional industries such as information technology, the initial driver was very much to create control over the project outcomes. New systems were late, over budget and often just plain wrong. Changes were a normal part of the business landscape, and accepted without question or consequence. Risks abounded, and were reacted to as they arose as best the team could. And everyone thought that there must be a better way.

Project management introduced a greater degree of certainty around project outcomes. There was a better understanding of what was required, and the activities and estimates required to deliver the project results. Change management provided a means of defining and understanding the consequences of absorbing change, and risk management allowed for a more proactive means of managing project uncertainties. Project were still often late or over budget, however. Worse, customers were in many cases less satisfied with the results of the project and with the team that delivered it because a bureaucratic wall had been introduced between themselves and the project.

And so the stage was set for conflict. The IT organization wanted more definition, greater rigour, additional sign-offs and better documentation in order to continue to gain control over the project. The customer wanted closer access to the project teams, more flexibility and responsiveness to their needs, and had no desire to go back for more funding every time they identified an additional requirement for the project. Overarching all of this are mounting pressures from senior management to manage budgets, maintain delivery targets and -increasingly - demonstrate that the promised business case and project benefits are actually being realized.

What is important to recognize here is that the desire for control is, fundamentally, a knee jerk reaction. There is no nuance of understanding behind it, nor is there an appreciation of what greater control would provide. In fact, while each side grasps for control they aren't even trying to control the same things. The emphasis of the IT organization is on trying to optimize the efficiency and reliability of delivery. The customer's focus is primarily on ensuring the relevance and value of the business outcomes, and that the project is able to respond quickly to changes of understanding, new market pressures or emerging opportunities.

This drive for control is unfortunate, as regardless of who wins the turf war, projects will not and cannot improve while the issues are defined in these terms. The primary problem is not who controls the project, but how the project is approached overall. In traditional project environments where the requirements and design criteria can be fully and completely defined up front, it is perfectly appropriate and in fact necessary to strictly manage projects to much more narrowly defined targets and constraints. Where the requirements and even the results of the project are uncertain, it is impossible to rigidly define the process, budget and schedule that will be followed. Yet while customers demand flexibility and responsiveness, in all too many cases the project managers and their departments are being rigorously held to budgets and schedules that were defined too early with too little information.

What is needed, therefore, is a different way of approaching projects. We need a way of managing project that allows the service organizations like IT to ensure adherence to processes and guidelines, and allows them to ensure that the actual solutions are consistent with existing standards and approaches. We need a way of responding to shifting customer needs and expectations. We need a way of ensuring organizational budgets and constraints are managed, and that there is full disclosure and understanding of project progress and success. We need a new way of thinking about projects that walks path between all of these points. But arm-wrestling for control is not the answer.

We don't have to constantly be stuck in this cycle of competition and conflict. That we are is in many cases a product of "that's the way we we've always done things around here" combined with a management system that values fiefdoms and individual political agendas over what is appropriate for the organization. To break this cycle first requires a change in how the organization thinks about its projects - what they are, why they exist, and what the expectations of them should be. By consciously shifting our reference point away from the project and towards the organization's needs we are also able to change our actions and behaviors.

Where Should The Responsibility For Project Management Really Lie?

A Critical Look At Executive Decision Making

Where Should The Responsibility For Project Management Really Lie?

When Projects and Organizations Collide

Guest — Sun, 05 Apr 2009 10:28:43 +0000

Let's start with a discussion of why the idea of a project-driven organization cannot come to fruition. The bottom line: most companies are not in the project management business. For those that are, they know it and they already function that way; they are a limited few — consulting organizations, architecture firms, construction companies. For the rest of us, we need to recognize the fact that our organizations exist for a very different purpose.

Most companies are in the business of providing a specific product or service. Airline companies are in the business of moving people great distances. Telephone companies provide dial tone and long distance services. Toy manufactures create plush toys with which to bribe our children. Drug companies sell pharmaceuticals that save or enhance our lives. But they aren't project-driven companies.

The dichotomy here, of course, is that these same companies rely on projects for their success. Projects are the means by which we create new services and enhance existing ones. They allow us to increase productivity and efficiency, introduce new technologies and implement new marketing programs. They provide the capabilities to build new infrastructure, retire plants and replace systems. But they do not represent the fundamental purpose of the business; they simply create it.

As technological and business advancements continue to accelerate and market pressures increase, projects are the basis of our competitive advantage. The company that can quickly, consistently and reliably deliver projects will enjoy a sustained market advantage as a result. While that company doesn't exist today, it will sometime in the not-too-distant future.

What the project management community needs to recognize, however, is that even once project management continues to deliver these continued advantages, it will not define how companies are managed. How companies compete, sure. How they create shareholder advantage, unquestionably. How they are managed, no. Not in my life time.

Once the project is over, it's over. Ownership is passed on to groups that project managers ascribe labels like 'functional' and 'operational' too. News flash. It's the operational guys that run companies. And it's the operational needs of the companies that their structures are designed to support.

The reason why this is true has been around since Taylor was studying operational efficiencies during the Industrial Revolution, accidentally discovering the profession of management consulting in the process. Organizational excellence — the means of efficiently producing drugs, computers and widgets or efficiently moving meals, movies or airplanes — is entirely dependent upon operational efficiencies. And we build our companies in such a way as to get them.

So what does this mean for the project managers of the world, and the organizations that are spending thousands and millions of dollars improving their project management effectiveness? Project management will always be a bolted-on function of operational organizations. You are only as good as your last project. Your continued employment will depend upon your next project. Deal with it.

Project management is an essential, strategic capability — and it's fundamentally expendable. Operational organizations will always require project management, but they can get it in a number of ways. They can engage firms to do it for them, they can contract individuals and teams, or they can build the capability themselves. But they'll never turn the company on it's head to do it.

At the end of the day, companies will gravitate to the most efficient and cost effective solution that still gives them a sustainable advantage. For most organizations, it doesn't matter how they accomplish this goal, so long as it is accomplished.

We are heading for a shake-up in how projects are managed in organizations, and it's likely one that will happen sooner rather than later. The role of project management is being recognized and valued. It won't stay the way it is, though. It will be redefined according to the terms of the companies that pay for it. It will be defined in a way that supports operational organizations, but it won't replace operational organizations.

Of course, operational organizations aren't doing a whole lot today to help themselves in this regard. Project success today most often happens despite the company, not because of it.

What Drives Organizational Success?

The Problems Of Top-Down Leadership

Guest — Thu, 02 Apr 2009 09:57:21 +0000

Given the diversity of beliefs and the passionate intensity of opinions, is there any right answer for how organizational change is accomplished? Is it dictated, or facilitated? Mandated or guided? Driven or led? And is there a single meaningful answer?

Some of the greatest innovations - not just of our lifetime, but throughout the ages - are the products of a select few individuals seeing, understanding and believing a truth where all others saw fallacy, lies and heresy. Any radical change to the established order of the world started with a handful of iconoclasts who dared to look at the world through a different lens. Whether the product of genius, madness or slightly unhinged creativity is irrelevant. They saw the world differently, and refused to accept a reality out of lockstep with their convictions, merely because theirs was the sole dissenting voice in a world of conformity.

Is corporate leadership today any different?

Numerous gurus, change programs and leadership models embrace the innovative power of the collective over the exercising of personal power by a dominant few individuals. Yet if innovation has historically been a product of the few wearing down the many, how does communal input foster quantum leaps in creativity? How does the consensus voice of the masses, collectively performing their established role, develop the impetus and insight to image a new order of things? Can they?

Changing the world requires an ability to embrace a vision writ large - very large. Creativity is the inspired re-ordering of the familiar into something new, and the foreign into something of value. It requires a mental remove from today's problems and issues, and an imagining of a broader future that is nothing more than dreams - but with a will to turn those dreams into a reality. Can we as a collective group step back from our day-to-day challenges, problems and concerns, and see a broader vision that can exist only because we will it into being? Can we step back and see the forest, when our daily functions require intimacy with not trees but bark?

But if the collective is the driver of corporate innovation, why is it the actions of individuals that seem most worthy of attention? Appointments of CEOs have massive influences on stock prices - up and down. Corporate performance is often described as a product of one individual's leadership. A succession plan - or failure to implement one - is regarded as a bellwether of subsequent corporate performance. The success of organizations like Coca-Cola, General Electric and IBM is not considered a product of the thousands of people they employ, but of the individual leadership qualities of Goizueta, Welch and Gerstner.

And yet leadership in a vacuum isn't leadership at all. What impact can any CEO have, speaking to an empty room? It is the people that work for an organization, and their willingness to accept, embrace and further a leader's vision, that ultimately determine results. Yet the most common measure of an organization is seldom the quality of its staff, and all too often the quality of its leaders.

This begs the question of whether leadership is truly the driving force, or merely the lowest-common-denominator explanation. Certainly the business press is far more comfortable with the appointment, dismissal or promotion of any one individual as an indicator of subsequent performance than the far more complex, uncertain and impenetrable analysis of the social, cultural and group dynamics within an organization and their ability to drive forward or bury organizational performance. We are a culture that likes easy labels, and complexity is therefore anathema. All too often, the only time that actual staff are regarded as having influence on an organization's success is when collectively grouped under the pejorative 'union'.

But when was the last time a CEO had a really great idea? In point of fact, when did a CEO last have time to have a really great idea? The innovation we love to embrace all too often happens in isolation and obscurity. We fail to appreciate the effort, single-mindedness of purpose, and sheer time it takes to develop a really great idea. The innovative CEOs of today became CEOs long after they were innovative. And all too often they are now enjoying the fruits of their much earlier labours, rather than developing new ideas themselves. When was the last time Bill Gates wrote a computer program?

Leadership is a key quality in successful organizational change. Innovation is equally critical. The bodies responsible for these disciplines, however, just might be mutually exclusive.

To quote an esteemed innovator of his own time, the playwright George Bernard Shaw, "The reasonable man adapts himself to the world; the unreasonable man persists in trying to adapt the world to himself. Therefore, all progress depends upon the unreasonable man."

Related Posts

The Road To Organizational Change

Strategy and Planning: Overcoming The Failures

Where Should The Responsibility For Project Management Really Lie?

Tools Aren't Process, But Process Is A Tool

Guest — Mon, 30 Mar 2009 09:46:16 +0000

Project scheduling tools don't do project management. If I had a buck for every time a client said "We need project management. Can you teach us how to use this tool?" I wouldn't need to be a consultant anymore. Project management tools let you 'do' project management like a word processor lets you 'do' English.

To successfully use a word processor requires a number of skills. Familiarity with a computer and its operating system is a given. An understanding of the principles of the program, and what buttons do what, also has value. More important, though, is the understanding of the principles of words on a page, and the thought process behind creating them. Which means that the fundamental principles of English are essential: grasping paragraph and sentence structure, intuiting subject and object agreement, and knowing not to split your infinitives (the Oxford dictionary notwithstanding) is a fundamental pre-requisite in successfully using a word processor.

Fortunately for Microsoft et al, the majority of people that purchase their word processors have been trained in the nuances of the English language since Kindergarten or earlier. The appreciation of the printed word is innate, as is the metaphor of word processor as electronic typewriter. When someone fires up their brand new word processor, they're way ahead of the game conceptually; familiarity is a technical exercise of understanding the buttons, not the concepts.

Unfortunately, our ready understanding of the concepts of word processors, spreadsheets and the like create an unreasonable expectation around the use and usability of project management tools. In point of fact, project management software is itself a misnomer. The tool that can manage a project doesn't exist, although there is an extensive array of project administration tools available.

What is important to understand here is the distinction between tools and process: process is how you accomplish your goals; the tools just make it easier. While the process of travel will tell you how to get from point A to point B, a car simply becomes a much more efficient tool than your feet in getting there. But the car can't travel on its own; it needs someone to guide it who understands the process, the goal and the desired outcome.

The promise of automation is not that computers will do our work for us; it is that computers will allow us to do our work faster, more efficiently and more accurately. We are still integral to the process. The best project managers are those that understand the process of project management well enough that they can execute it with no automated support whatsoever. Which isn't to say you would want to, necessarily; it just isn't efficient. But if you don't understand the process you are trying to execute, there is no amount of automation that can help you get there from here.

Project software is designed to make administration easy. It cannot make management decisions; it will not be able to decide the appropriate duration or effort for an activity, who the must appropriate resource to perform the activity is, which other activities should proceed it, or even if the activity belongs as a part of the project. These are decisions that are made by the project manager without the benefit of automation assistance. Once you have established all of these criteria, however, the software makes it incredibly easy to adjust to changes. And the one truth of project management is that things will change.

Success in project management, therefore, is not a question of having the best - or even the latest - tool. The toolset you use should be a secondary consideration, and one that is made long after you have developed a familiarity and understanding of how you work as a project manager.

Choosing project management software before you have developed and established your process will not solve your problems. In fact, it will create more problems - the reality of software creates the illusion of process, which simply heightens expectations around results. Organizations and project managers need to think long and hard about how they are going to manage - individually and collectively - and what they need in order to establish that base capability before a software package can even begin to be of assistance.

Once you can write, you can use a word processor. Knowing how to use a word processor, however, doesn't mean that you can write effectively. The same principle is even more true for project management.

After all, software doesn't manage people; people manage people.

Related Posts

Is Project Management a Fad?

Portfolios and Project Management Organizations (PMOs)

Projects Are Strategy

Guest — Fri, 27 Mar 2009 09:33:46 +0000

The column builds on the fundamental principle that many of the challenges stem from the fact that project management is not the primary purpose of organizations, and never will be. Companies are created, structured and run primarily to deliver operational products and services. Projects, however, are still critical to the business success of these organizations - in creating, enhancing, replacing and retiring products and services in response to competitive and market demands. The challenge, then, is to arrive at an approach to managing projects in organizations that can co-exist with their current operational focus. This series addresses the practical steps that organizations can and must take to successfully create an effective project management capability.

In the world of organizations, all work can be divided into two categories: you are either running the business or you are changing the business. The act of running the business is governed by a host of well defined processes, techniques and disciplines collectively described as operations management. If you are changing the business, you are doing projects. What is frustrating for many senior managers, and some project managers, is that the process of changing the business is often so poorly managed. In many instances, change efforts are not even identified as being projects. Responsibility for these 'accidental projects' is assumed by management teams who don't see them as such, and may not even recognize that the discipline of project management exists and could provide meaningful support.

Nowhere is this more true than in the development and articulation of strategic plans. The real role of a strategic plan is nothing less than establishing the blueprint for changing the business. Practically speaking, it should identify the activities and the full scope of effort necessary to manage the changes that are expected - from the creation of new products or markets to the improvement of productivity or the establishment of production targets. To validate this, think of your own organization: if you were satisfied with the same quality, productivity and cost structure, and were to continue to provide the same products and services in the same quantities and at the same price to the same customers, you wouldn't need a strategic plan. In a nutshell, the strategic plan defines what is going to be different, this year or for the next few years.

The implication of this statement is that all projects should be aligned with the strategic plan, and the strategic plan should articulate all projects that are to be done within the organization. Whether establishing new locations, launching new products, entering new markets or making changes to productivity and quality, all of these changes should derive from the strategic plan. So too should all of the smaller changes - whether optimizing production lines, improving process quality, enhancing information systems or establishing a relationship with a new customer. Each of these efforts is a project, and should be managed as such, and any project being undertaken should clearly align with and support the strategic plan.

Now, there are those that will argue that you can't plan all of these activities up front, and as such it is inappropriate for them all to be defined in the strategic plan. To a certain extent, this is true - many initiatives can not be identified during a formalized annual planning cycle, and will emerge throughout the course of the business year. This does not mean that these efforts should not align with the overall goals and direction of the strategic plan, and that this alignment should not be formally validated prior to initiating the project.

This is also not to say that the senior management team must therefore review, prioritize and approve each and every project prior to its initiation, no matter how small. The best strategic planning processes have multiple layers of definition, from the overarching corporate objectives through to individual business unit and departmental plans. The key emphasis is on ensuring alignment from the organization to the division to the department. While each department will define their own plans and review them with their immediate management teams, each is still responsible for running their operation and overseeing the projects they are responsible for. While senior management may not formally review and approve every departmental or divisional initiative, there should at least be a level of auditability that verifies each project aligns with the rest of the organization.

The importance of this alignment has been driven home through consulting with several customers around their business planning and prioritization processes. What these engagements have illustrated is that in the majority of companies only a small percentage of projects are actually visible at a senior management level. These projects are usually corporate in nature, having a far-reaching impact on the organization's health and future well-being and often representing a significant investment of corporate resources. What is unique about these projects is that they often represent a significant majority of financial investment in projects - up to 75% of total project expenditures in some organizations - while representing a much smaller percentage of overall staff effort. The majority of staff hours, again typically between 60% and 75%, are actually spent on projects that senior management is not even aware of. Given the significant degree of human capital associated with these projects, organizations have a responsibility to ensure that it is effectively managed.

Once we recognize that the work of strategic plans is really project work, the reason for many organizations failing to realize their strategic goals also begins to become clear. The failure rates for projects continue to be quite high, even where formal project management is being used - in some organizations, as much as 70% or 80%. When initiatives are being managed without the benefit of formal project management, the failure rates are even higher. We need to start making better choices about how we realize the objectives of our strategic plans, and to recognize and approach the projects they define using formal management techniques.

More importantly, however, we need to recognize that projects are a threat to the operational status quo -operations management is designed to ensure consistency and repeatability, and to the greatest degree possible minimize variation. By definition, projects introduce change into operational processes. They introduce variation, and certainly at the outset will have a detrimental effect on consistency and repeatability, until the new mode of operations can be embraced and adopted. As a result, there tends to be a strong and innate opposition to projects, and often very little enthusiasm for supporting them.

To be effective, organizations need to have far greater alignment between projects, operations and strategy-making. We need to make better choices about the strategies we adopt, and the projects that result from them. We need to ensure that the projects we are undertaking do in fact align with the strategic choices of the organization. And we need to better manage the operational impacts that result from the projects we undertake. Only then can will the work of organizations be truly aligned.

Related Posts

Organization Success: It All Comes Down To Projects

Strategy and Planning: Overcoming The Failures

A New Way of Thinking About Organizational Projects

What I Learned At The Olympics About Managing

Guest — Tue, 24 Mar 2009 08:55:07 +0000

This column was originally published during the Nagano Winter Olympics in 1998. In honor of the Salt Lake City games, we've brought it out, dusted it off and are pleased to place it back in the line-up. Enjoy.

Fundamental to our society is the concept of keeping score. We measure ourselves (and more importantly, those we view as competitors) by income, social status, wealth, number of cars. Raw measures that provide an automatic comparison of how we stack up, and how far we still have to go. As the saying goes, he — or she — who has the most toys when they die wins.

There is no question that we are a competitive breed. Darwinism is a finely honed and decisive discriminator of our actions and thoughts — socially and in business. And also in sports.

Our athletes are our new gladiators. Occasionally no less violent, and certainly no less gripping, whole nations are captivated and motivated by how well their team performs. This is no better illustrated than at the Olympics, where each nation keeps score of how well their athletes rack up. How many medals won and lost. The score in the women's hockey game between Canada and the U.S.

Imagine yourself as the new coach of the Canadian women's hockey team. Last three games ended 4-2, 5-6 and 8-2. What do you, as coach, need to do to improve the team's performance?
Not enough information? Isn't it reassuring to know that you can rely on stats for each player — shots on goal, assists, goals. The strengths and weaknesses of each person are known and quantified, as are the stats for the team as a whole. Moreover, as coach, you have scouts out gathering exactly the same information on your competition; strengths, weaknesses, opportunities, threats — the information you need to make sure that when your team hits the ice, you have given them the greatest amount of information possible to ensure success. And don't think the curling teams are any less competitive.

As a fan, you probably also consider yourself fairly well informed. There are too many armchair coaches to bely that fact. You know the stats, you know the plays — and you probably think you can execute pretty well.

Pity what happens on Monday when you get back to the office, isn't it?

Companies are no less goal-driven than sports teams. Revenue, profitability, market share, EVA — important elements of the scorecards used in determining corporate performance. Moreover, the incentives of the marketplace are directly tied to these means of keeping score. Executive pay, stock options, stock price, credit ratings, and a disturbing majority of corporate statistics are driven by some combination of these top-level scores.

Yet compared to their more athletic counterparts, corporate managers are woefully under-informed and unprepared to make decisions that can directly influence these numbers. You cannot manage a company by the balance sheet — it is merely your scorecard. So, what statistics do you know about your team? What are their strengths? Their weaknesses? Where are the opportunities to seize competitive advantage?

And what about your competitors?

Unless we as organizations learn to ignore the score, and concentrate on understanding how we play the game, winning on the corporate ice-rink falls down to inherent talent and plain dumb luck.

Repeatability, consistency and success — gold medal winning performances — rely on a much more solid basis of understanding of our capabilities, and those of our competitors. Managing successfully requires access to a host of meaningful, useful and relevant statistics — performance measures — in order to harness our competitive strengths, mitigate our weaknesses, and seize competitive advantage.

Because the company that scores the most points wins.

Negotiation Tactics for Project Managers

16 Project Manager Traits

The Best Project Management Methodology

Project Management as a Microcosm

Guest — Sat, 21 Mar 2009 08:44:53 +0000

Companies today, recognizing they face serious cultural, behavioral and management challenges, often look to project management as a quick-fix band-aid that can alleviate - or even eliminate - many of the problems in the organization. Unfortunately, this approach is exactly backwards. The way project management is conducted is a direct reflection the larger management behaviors of the company; a project is in fact a microcosm of the organization as a whole.

Like a sample under a microscope, the management challenges of the organization come into sharp focus in the project environment. The biases, preferences, decision-making styles and hierarchical challenges are all magnified in intensity. Warts and all, the problems of the organization become clear to those responsible for or affected by the project, while the myopia of the organization as a whole just intensifies.

What is interesting about this phenomenon is that the organizations that most often look to project management for a quick fix are those that are the most managerially dysfunctional. They behave like a junkie, believing that one more hit and they will be able to put the problems of the past behind them.

Take as an example the management team of an IT department that cannot make a decision for fear that their customers will not approve. Decisions are delayed until the last possible moment, in an effort to avoid making an incorrect one. Customers are constantly sounded out on their preferences and opinions, and regularly assured that their top issues are IT's top issues. Yet decisions are only made when forced, and even then are made on the basis of what will be perceived as most popular rather than what is right. The result is frustration on the part of the customers, combined in equal parts with irritation, annoyance and a sneaking suspicion that IT will tell them anything to appease them and make them go away.

Enter the project team that is brought in to resolve a particular customer problem, in the belief that project management will solve the organization's failure to otherwise make decisions. As the project team identifies and starts to try to resolve problems, the IT management team digs in and resists changes that it believes will be unpopular. The customer organization, finally getting some attention, weighs the project down with every wish list item ever documented. The other customers are up in arms because their priorities are being ignored in favour of someone else's. And the project team is bound up in management inertia as it tries to clearly establish requirements and manage scope in an environment where they simply cannot get a decision.

The reality is that projects become mired in the same management miasma as the organizations in which they are created. Without addressing the underlying problems of the organization, projects cannot hope to be successful. Failure of the organization to effectively prioritize will result in a lack of prioritization in its projects. Failure to ensure sufficient resources and skills at an organizational level result in resource allocation and availability issues at the project level. Failure to place an emphasis on plans and budgets in an organizational context results in rudderless projects without direction or boundary.

There is no question that project management has its own challenges, issues and barriers to success. Many of the largest barriers, however, begin as organizational problems. Many of the immediate challenges and hurdles encountered at a project level are not in fact project management problems - they are general management problems whose symptoms have simply festered and spread.

To change, then, first requires recognition of our organizational demons as the diseases they are and resolving to eradicate them. The management team must recognize and acknowledge the organizational challenges, and the degree to which they are responsible for creating them, and commit to actively taking steps to address them. Project management can in fact be an enabler in this change process, but only in an environment where the problems are acknowledged and the project manager has the authority to confront the source of the problems head-on and challenge the behaviors of both the organization and the management team. This takes a great deal of fortitude on the part of the project manager, and even more humility on the part of the management team.

At the end of the day, project management is not a band-aid solution to an organization's management problems. But it is an excellent means of placing them under the microscope and seeing them for what they are.

Organization Success: It All Comes Down To Projects

Portfolios and Project Management Organizations (PMOs)

Measuring Organizational Change

Guest — Wed, 18 Mar 2009 08:18:07 +0000

As I manage various organizational change projects, I never cease to be amazed by one fundamental truth that - while unspoken - is the single greatest burden that every successful change project must overcome: management acceptance. No more is this true than in projects implementing performance measurement programs.

The reason that this truth often goes unstated is worthy of special recognition. In many - if not most - cases, the management team that ultimately has the greatest difficulty in coming to terms with the nature of the change is frequently the same management team sponsoring the effort in the first place. Paradoxical? Perhaps, but there are some clear drivers of why this is so.

Let's start with the nature of performance measurement implementations. The underlying rationale is to clearly understand, manage and improve the fundamental performance of the organization. The driver of performance measurement is to quantifiably make visible the key performance drivers of the organization, and create a clear sense of manageability. Candidate measures include productivity, quality, cycle time - the list is as long and as varied as there are candidate organizations.

As I have pointed out in other columns, measurement is personal. One of the key benefits - and one of the fundamental drivers that should in all instances be present - is a clear identification of individual contribution. What impact have I had on the organization? How much revenue have I generated? How many defects have I eliminated? How much has my productivity improved?

Let's deal with the first one: How much money did I make for the company today? Imagine, for example, that you are a service technician, and that for each call you make the company receives $100 in revenue. Make ten calls in a day, and you have contributed $1,000 to the bottom line of your organization. A department of 10 technicians, each performing at the same level, contributes $10,000 to the bottom line each and every day. An easy measure to determine.

So how about the manager of that department? How much revenue did they generate for the company that day? You can't keep claiming the same contribution to the bottom line at each progressive stage up the org chart. The benefits occur once, and once only. This begins to illustrate some of the problems managers have in accepting performance measurement as a concept; those that sponsor it fear that the measures will reflect poorly on them, even if they themselves perceive that they provide a valuable - or essential - function. As such, resistance at a fundamental, personal level is virtually guaranteed.

Part of the problem we are encountering is one of a clear understanding of role. Managers, by their nature, rarely produce direct revenue for the organization. The further you travel up the organizational hierarchy, the more abstract this problem becomes. The logic is simple: the front line is where the rubber meets the road, and where true revenue is generated; the further you are from the front line, the more removed your direct impact on revenue generation.

The key word here is direct. What is being missed in the discussion is that the manager's role is most often an indirect one. The role should be one of leadership: managing costs, improving performance and minimizing defects; all of which are impacts that are felt over the long term. Given these aspects of the role, however, there is a clearly defined opportunity to make a significant impact to the organization, and a measurable one at that. Unfortunately, many managers choose to ignore the value of indirect benefits, or believe that the organization does not perceive them to be sufficiently tangible.

In many cases, managers also find themselves in positions where they are constantly supervising, managing expectations, fighting fires, and dealing with issues and problems. Those who see this as their role are the ones that display the greatest resistance to the concept of introducing performance measures, and with obvious reasons. There is no direct value being created - the process is barely being managed, let alone improved. A focus on improving the process and driving accountability to those directly responsible for execution would eliminate a great deal of churn. The challenge comes when a manager enjoys the fire fighter mentality, and has no desire to improve the process as it diminishes their personal sense of value and worth.
At the end of the day, the argument answers itself. For organizations that seek to improve, performance measurement provides the framework to put the levers of control in the hands of those that truly need them, and of necessity highlights and encourages the elimination of waste, inefficiency and ineffectiveness. At all levels of the organization.
You just have to want it badly enough.

What I Learned At The Olympics About Managing

Portfolios and Project Management Organizations (PMOs)

A New Way of Thinking About Organizational Projects

Organization Success: It All Comes Down To Projects

Guest — Sun, 15 Mar 2009 07:38:13 +0000

Organizations will grow or fail entirely based upon their success in managing projects. Project management will be the yardstick by which future organizational success is measured. To fail is easy: organizations must simply do nothing, and so will begin an inexorable slide to oblivion as new capabilities are ignored and new opportunities are missed. Success is a much more difficult journey, but simply launching projects is not in and of itself a sufficient guarantee.

There are three fundamental questions that any organization must address if it is to be successful in managing projects at an organizational level:

Are we doing the right projects?
Are we doing our projects the right way?
Are we realizing the promised results from our projects?

For most organizations, even where there has been a concerted effort to implement a project management capability, these questions cannot be answered objectively. While there might be an intuitive sense of what the answer is, or a rationalization based upon a belief of what the answer should be, most companies do not have the processes or toolsets necessary for objectivity.

The biggest reason for this failing is the way that most organizations think about their projects, to the extent that there is an organizational focus at all: as discrete, isolated activities. The reality is that projects do not operate in a vacuum: they compete with each other for the company's time, money, resources and attention. The project management practices of most organizations, however, ignore this reality.

Part of the problem with how organizations view their projects is that there are few advocates who are promoting a different perspective. The vast majority of project management courses address how to manage a single project, and the few that allow for an organizational context do so only in passing. Most software products in the marketplace take a single project view, and current repositories have limited reporting capabilities from an organizational perspective. PMI's Project Management Body of Knowledge completely ignores the question of how organization's approach their overall portfolio of projects.

To be successful in managing projects as an organization, it is necessary to look at the full scope of practice of the organization. Financial, budgetting and accounting practices must embrace the concept of projects. Strategic plans must drive the definition of projects. Projects must successfully manage the transition of the underlying operational processes they affect. And this integration must be managed from a holistic perspective that looks at all of the organization's projects together.

No organization that I am aware of takes this approach today. Yes, some touch on aspects of each of these issues. But none take an objective, process-based approach to defining their projects, executing them, and ensuring that the promised business outcomes are in fact realized. And none can objectively, quantifiably answer the three questions identified above.

Project success in organizations will depend upon putting the practices, processes and toolsets in place that support delivering objective answers to the questions I have posed. Solutions exist, although they are far more easily defined than they are implemented. The companies that can break down the barriers to their use, however, stand to reap significant rewards as they outpace their competitors.

As a company, Interthink Consulting works with organizations facing these challenges today. This column has been launched to explore the barriers that prevent effective project management in organizations today, and the strategies that can be adopted to overcome them. In writing it, we have consciously taken an organizational perspective, for the organization is the arena in which many of the problems are created, and in which all of them must be resolved.

Is Project Management a Fad?

A New Way of Thinking About Organizational Projects

A Critical Look At Executive Decision Making

Guest — Thu, 12 Mar 2009 07:27:19 +0000

We have all seen the statistics regarding project failures — by even conservative estimates, the majority of projects to date either fail to meet their objectives or are never delivered at all. Moreover, we have all sat through innumerable presentations dissecting the causes of project failure and prescribing the necessary and appropriate solutions. The reality, however, is that for many projects failure is dialed in from the beginning. The greatest challenge that organizations face is not how the project is managed, or who manages it — but simply how the choice is made.

This simple truth was reinforced for me through a number of recent corporate presentations, in which project managers were being introduced to a new framework for managing projects. While the process that the framework outlines is straightforward, easily understood and readily adapted and scaled to a variety of projects, there was a huge amount of overall resistance to its initial use and adoption. A certain amount of resistance can readily be attributed to any organizational change effort, but the reaction of participants seemed inordinately negative.

It goes without saying that any change will have its negative influences, and certainly this engagement was no different. Given the amount of effort that had gone in to ensuring buy-in, acceptance and validity of the proposed solution, however, the reactions were surprising. There was strong executive support and commitment, extensive consultation from project managers that would use the process, and a comprehensive training and education process had been developed to support staff in understanding the process, their role within it and the commitments and expectations of the organization.

In pursuing the source of this resistance, what became clear was that its source had little to do with the validity of the project management framework itself. In fact, there was almost universal acknowledgment that the framework made sense, provided a great deal of value and was readily adaptable to the wide array of projects the organization undertook. The problem was rooted in the fact that the organization expected improvement in project performance as a result of implementing the framework.

Arguably, it was as desire for improvement in project performance that led the organization to adopt a new project management framework in the first place, so this objective should not on the face of it seem unreasonable. What was of concern was the attainability of this objective given how projects were evaluated, prioritized and selected within the organization. The operating belief in the organization was that by hiring better project managers and establishing better project processes, improved project results were attainable. At the same time, senior management within the organization clearly believed that whatever choices they made regarding the projects that they chose to initiate were fair game — that the decision-making process was separate and distinct from what was required to successfully deliver them.

The concerns expressed by the project managers was a reaction to the fact that a significant number of project problems begin with how projects are dependent upon they are initiated. Decisions made at the outset can have the impact of effectively handicapping a project, short-circuiting the impact of any attempts to apply proper project management. From imposing a solution without a full appreciation of the requirements to fixing the cost budget without any clear appreciation of the actual underlying work that funding must pay for, these constraints — if accepted — can railroad the project team into a situation that is almost certainly destined for failure. While a good project management process, for example, recognizes that progressive refinement of the estimates is appropriate as more information becomes known about the project, imposing a budget can have the net effect of turning the project into an exercise of how much project can be done for a defined amount of money.

While the fact that these decisions get made is certainly important, of more significance is an understanding of why sponsors and executives make them. Possibly the simplest explanation is 'because they can', but that doesn't really speak to the underlying motives that actually leads them to make the decisions they do. All too often, it is for the same optimistic reasons that have plagued projects in the past — the belief that a project should only cost that much, and if only the team tries really hard they can pull it off. In other instances, it may be a consequence of the age-old practice of accommodating the express or perceived wishes of their bosses. It can be a results of believing that creating artificial boundaries is a way of motivating teams to 'think outside of the box'. Sometimes, it comes down to the simple and sadistic pleasure of watching someone squirm — the corporate equivalent of frying ants with a magnifying glass.

What is clear from all of this is that while project management itself continues to mature and improve, the results that projects deliver won't significantly improve unless the full lifecycle of decision making — from initiation at the beginning through to the process of value realization at the end — align to create a consistent, logical and related process of decision making. This article begins a new series that will explore these issues in details. Through it, I hope to be able to inject some much-need rationality into a process that many view as overly irrational. Stay tuned.

Related Posts

Portfolios and Project Management Organizations (PMOs)

Two Project Management Metaphors

Projects and Investments

Project Politics

Marios Alexandrou — Mon, 09 Mar 2009 07:24:33 +0000

Acknowledging that projects are going to be subject to the personal agendas of its team members doesn't making it any less frustrating. Michael Hatfield has taken it upon himself to offer 4 classifications for each member of a project team in an effort to anticipate the potential political issues.

Supporters
As the name suggests, these are the people that are willing to support you and are therefore worthy of your trust. If you walk in to a room and cause the conversation to suddenly stop, you can assume that these people are NOT supporters. On the other hand, anyone that are eager to show off any effort that supports your efforts is likely a supporter.

Fence-Sitters
These folks will support you down the road as long as you prove to them that you are worthy of it. If a team member constantly challenges you, but does so in a constructive manner, they could be a fence-sitter.

The Potentials
These people will need extra time and effort to turn them in to supporters. Rewarding your supporters can swing these folks to your side as they learn that there's a benefit to being a supporter themselves.

True Enemies
And finally, the people that will never support you no matter what you do. One strong sign of this type of person is if you observe them in repeated conversations with your peers or superiors. Also, if a team member challenges you in a such a way that they are trying to make you appear inept, then they're like enemies.

Related Posts

Project Teams

PMP Certification

Project Management Career Paths

The Art of Project Scheduling

Marios Alexandrou — Fri, 06 Mar 2009 05:52:32 +0000

Note: The following was taken from Nick Jenkins' A Primer on Project Management. Nick's primer was released
on the creative commons license making the below subject to the same licensing terms.

Why the "art" of project scheduling?

If it were a science then every project would be delivered on time!

This sadly does not seem to be the case. In fact, overruns have become so common that people have lost faith in project deadlines and view them with a great deal of cynicism.

In truth, the art of scheduling is based on experience and the more experience you have, the more accurate your schedule will be. However, you can still produce an accurate schedule by following some simple rules.

Principles of Scheduling

Rule #1

Never give off-the-cuff or unconsidered responses i.e. don't commit to something you can't deliver).

Scheduling is one part prediction and one part expectation management. If you are pressured into picking a date "on-the-fly" at a random meeting you can bet that the date will not only be wrong, it will come back to haunt you. A considered response when you have had time to evaluate all the factors is much better. A date picked out of the air is good to no-one, least of all yourself.

Rule #2

Eliminate uncertainty wherever you can.

The more specific you can be in your project planning, the more accurate your schedule will be. If you leave functionality or other items unspecified in your plan, then you will, at best, only be able to approximate them in the schedule. Don't go overboard, though, there is a balance. If you are spending time adding detail to tasks which will have no impact on the project delivery date, then you are probably wasting your time.

Rule #3

Build in plenty of contingency to cope with variation.

No matter how well specified your project and how accurate your schedule, there will be the inevitable random influences that will wreck your carefully crafted schedule. People get sick, equipment fails and external factors join together in a conspiracy to see that you miss your target date. In order to buy yourself some insurance you should build in an adequate amount of contingency, so that you can cope with unexpected delays.

You should also spread contingency throughout your project timeline and not just place it at the end. If you only have one pool of contingency allocated to the end of your project you are leaving yourself with a large slice of uncertainty. By breaking it up and spreading it throughout your project you allow yourself more options and are able to control the project more closely. You can also "buy back" time when you return unused contingency to the project.

Rule #4

Pick the right level of granularity

When drawing up your schedule it is important to pick the right level of detail. If you are going to require daily updates from your team then it makes sense to break into day-by-day chunks. That way everybody has the same understanding of what must be achieved by when.

On the other hand if your project has large portions of time devoted to similar activities, testing for example, then it may be better to simply block-schedule one or two months of testing. Maybe you can leave the details up to your team, it all depends on the level of control you want.

In most projects I've dealt with my optimum level of granularity is a week. This means that tasks are scheduled on the basis of the number of weeks they take. Week-by-week is much more comfortable for most people since finishing a task by the end of the week seems more natural than finishing it on a Monday or Tuesday.

Day by day scheduling can provoke more overhead than you really need. If a task is scheduled to be completed on Wednesday but due to difficulties it cannot be completed, it is unlikely that it will be finished on the Thursday, even if a team member predicts it to be so. It is more likely it will overrun by a couple of days and finish sometime on Friday, meaning that subsequent tasks can't take place until the next week. If I schedule day-by-day then I spend all of my time updating the
schedule and not managing the project. On the other hand if I schedule week-by-week it is much easier to cope with such small variations. If something scheduled for "the week beginning Monday the 21st" is delayed by one, two or even three days, then subsequent tasks can either be moved comfortably or may not even be affected at all (depending on my level of contingency).

The only exception to this is where I need to force the pace of a project. I do this by imposing tighter deadlines, to the day or even down to the hour, for completion of tasks. A higher level of control however implies a higher level of attention and if I do this, I know it has implications for my own work-load as well. On a finer grade of schedule I will need to pay closer attention to
individual tasks to ensure their completion.

Rule #5

Schedule for the unexpected

Project management is the art of handling the unknown. Often events and circumstances you could not have foreseen will interrupt the flow of your project. It's your job to take them all in your stride. Schedule for the most likely delays and cope with them should they arise. If experience or instinct tells you that a certain type of task will overrun, then anticipate it, pad it with some contingency and make sure you have adequate resources on hand when it comes up.

A good way to cope with this is to implement a bit of impromptu risk management (see Risk Management). By anticipating likely risks and prioritizing them you will be better able to deal with the unexpected! It also makes a lot of sense to let someone else help assess the risk to your project.

Related Posts

The Seeds of Project Failure

Surviving a Project Audit