A Four-Part Series

By Aaron J. Shenhar

PART 4: THE NEW ADAPTIVE PROJECT MANAGEMENT FRAMEWORK

Based on our research we suggest changing the paradigm of project management and accepting things as they are. The new framework is success-focused, flexible, and adaptive, and we can simply call it the “Adaptive Project Management Model;” it differs from the traditional approach in several ways, as shown in Table 1

According to this model projects are not just a collection of activities that need to be completed on time. Projects are business-related processes that must deliver business results. They are not predictable or certain. Rather, they involve a great deal of uncertainty and complexity, and they must be managed in a flexible and adaptive way. Planning is not rigid, fixed, or done once and for all; instead, it is adjustable and changing, and as the project moves forward, re-planning is often appropriate or even unavoidable. Project management styles must adapt to the specific project and its requirements, and one size does not fit all. While this approach represents a shift in thinking, it is inevitable to meet today’s organizational challenges. While no framework could provide all the answers, we believe that every organization can significantly improve its business results and achieve more homeruns from its projects if it will consciously apply the adaptive project management frameworks.

One final word: We do not suggest, however, eliminating the traditional approach. Rather, we are building on it. Many elements of traditional project management continue to be useful; yet, the overall approach will be augmented. As established by the conventional approach, each project must have a work breakdown structure, a schedule, a budget, an organization and a process. All those are necessary building blocks for well-organized successful projects. These building blocks will only form the baseline to leading the project in a flexible way. Not only do projects have to monitor and review their progress, they must periodically examine the need for the product and the customer’s position. Are the initial assumptions still valid? And if not, what adjustment does the project have to make in order to guarantee better success. Furthermore, in many projects it is impossible to build a clear and detailed plan. The uncertainty involved is simply too high to enable creating a clear project plan with all its bells and whistles. Instead, companies must initiate pilot programs, namely, small-scale efforts that will help remove some of the unknowns before the company can commit to the major large effort. In other situations, managers must create product prototypes that will be tested by customers before the final product requirements are set and determined.

In sum modern projects involve a great deal of uncertainty and complexity, as well as other constraints such as time, political pressures, economical risks, and many others. Each project is unique and it has to be managed it its own way that best fits it unique characteristics, risk and complexity. Only after companies learn how to manage projects in an adaptive and flexible way, will projects become the powerful competitive assets that they can be.

PART 1: THE PROJECT MANAGEMENT OPPORTUNITY

PART 2: WHY MANAGING A PROJECT BY THE BOOK IS NOT ENOUGH

PART 3: WHAT IS MISSING IN TRADITIONAL PROJECT MANAGEMENT

A Four-Part Series

By Aaron J. Shenhar

PART 3: WHAT IS MISSING IN TRADITIONAL PROJECT MANAGEMENT

As mentioned in the previous article, the current, standard, and formal approach to project management is based on a predictable, fixed, relatively simple, and certain model. It is also generally decoupled from the changes in the environment or the business needs; once you created the project plan, this plan sets out the objectives for the project, and the project manager must execute the plan, using a “management-as-planned” philosophy. After the project is launched, progress and performance are assessed against the plan and changes to the plan should be rare, and if possible avoided. Consider the following two major drivers of project management today:

The triple constraint: Project managers see their job as successful when they are able to complete the project on time, within budget, and achieve performance (or requirements) goals. This has famously been named “the triple constraint” (or “iron triangle”) of project management and deviations from it are seen as a negative sign, which must be prevented or corrected.

One size fits all: Many executives and managers assume that all projects are the same, thus suffering from the “project is a project is a project” syndrome. They expect to succeed by simply following a standard set of activities as outlined in the conventional project management books, which currently do not include guidelines for distinction among projects and for selecting the right approach for the right project.

In their struggle to keep projects on track, both executives and teams get frustrated when they are trying to fulfill unrealistic expectations of stability. Worse, in their effort to focus the project on the triple constraint, project teams often lose sight of the business rationale behind their projects, that they must satisfy a customer and achieve business results, and not just meet project requirements. And when they try to follow a standard set of rules for all projects, they often employ the wrong approach to their specific project.

The classical drivers of project management are no longer enough for today’s business environment. The traditional model fits only a small group of today’s projects. Most modern projects are uncertain, complex, and changing; and they are highly impacted by the dynamics in the environment. Virtually every project we studied underwent changes that were unpredictable upfront, and none of the projects was completed exactly as planned. Furthermore, as we found, projects differ in many ways, and “one size does not fit all.” In order to succeed, projects must be adjusted to the environment, task, and goal, rather than stick to one set of rules.

PART 1: THE PROJECT MANAGEMENT OPPORTUNITY

PART 2: WHY MANAGING A PROJECT BY THE BOOK IS NOT ENOUGH

PART 4: THE NEW ADAPTIVE PROJECT MANAGEMENT FRAMEWORK

A Four-Part Series

By Aaron J. Shenhar

PART 2: WHY MANAGING A PROJECT BY THE BOOK IS NOT ENOUGH

The current techniques as used in the discipline of project management form the necessary basis for learning and understanding what project management is all about, but they are insufficient to guarantee a project’s success or to address the needs of today’s dynamic and uncertain projects.

We have seen projects that were managed exactly as required “by the book”–and still failed. They followed a structured process of planning and execution, which is common in the profession, and even when completed on time, they ended up in disappointment to management and clients. And we have observed other projects that did not follow any acceptable structure or process, or did not have a full plan with all its elements, and yet they turned out to be outstanding successes, bringing-in value and fame to their performing organizations and great satisfaction to their customers.

The discipline of project management is based on an outdated model that assumes that projects are successful if they meet their time and budget goals. Once the project is launched, it must continue to its end to meet time, budget and requirements goals. Rarely do projects focus on business results or on changing at mid-course to better adjust to customer needs.

Most of today’s project problems are not technical, but managerial. When technical errors cause projects to fail, it is usually management that failed to put the right system in place so that these errors will be detected in time. We also realized that the current practices of project management are insufficient to predict project problems or to solve them. And we found that even if you do everything according to the conventional well-established practices of project management, you may still fail.

Ironically, these traditional practices remain typically unchallenged by top management. As a result, many project teams are left on their own. They often struggle to keep their projects on track while trying to fulfill unrealistic expectations of stability; often highly detached from dynamic business needs and changes in the environment.

Our conclusion is simple. There is more to project success than following a standard set of rules. It is not the tools or applications, nor is it the lack of process. The problem lies in the mindset and the assumptions that are driving the traditional approach to project management, rather than in process or practice. The critical questions are: can we help project teams make the right assessment before presenting their project proposals to top management? Can we show executives how to ask the right questions and foresee danger before they make a commitment to a project and before it is too late? And can we guide project teams on how to adapt their project management style to the right circumstances, environment, and task? It seems that managers at all levels need a new framework and a new language to communicate with each other about projects.

PART 1: THE PROJECT MANAGEMENT OPPORTUNITY

PART 3: WHAT IS MISSING IN TRADITIONAL PROJECT MANAGEMENT

PART 4: THE NEW ADAPTIVE PROJECT MANAGEMENT FRAMEWORK

A Four-Part Series

By Aaron J. Shenhar

Executive Summary
Projects are the engines that drive innovation and change. Yet top management ignored them for a long time. Thus many projects today do not meet their objectives. In order to unleash the hidden potential that exists in projects companies must learn how to manage project in a highly adaptive, flexible, and strategic way. This change can make projects one of the most powerful competitive assets of modern corporations. In this series of articles we outline the potential that exists today in project management and what organizations can do to take advantage of this power.

PART 1: THE PROJECT MANAGEMENT OPPORTUNITY

Although projects have been around for thousands of years and project management as a discipline about fifty years, there are two reasons why projects and project management are becoming more and more important today to almost all organizations and businesses. First, the share of on-going operations in most organizations is on the decline, while the share of projects is rising. This trend began already in the early 1900s during the industrial revolution, and it is accelerating in almost every organization or industry: Not only do product lifecycles become shorter; today’s customers require greater variety and more choices, forcing companies to offer more products. In addition, market globalization is forcing businesses to respond to local markets and to low-cost competition around the world.

The second reason why organizations need to look closely at their project management is that across the board you may find that most projects today do not meet their time and budget goals and many do not meet their business objectives. Study after study shows that only one out of three projects is really considered successful. Thus, if two thirds of the efforts going into projects do not create the expected value, there is clearly a reason for concern.Ironically, during the last few decades many organizations focused on improving their operations, but not their projects. This trend goes back to the turn of the Century when Frederick Taylor developed the scientific management principles, which greatly influenced the evolution of mass production systems, and it continued to this date with more recent concepts such as Just In Time, Lean Manufacturing, Reengineering, Supply Chain Management, and of course, the latest one, Six Sigma.

Although operational efficiency is important, it has its limitations. With time, at least conceptually, all companies may reach a similar level of efficiency. Additional investment in efficiency may not bring the advantages that it has created in the past. At best it may help you stay in the game and not fall behind. For comparison you may look at quality, which during the last decade has become a must, rather than a source of competitiveness as in the past.

However, no business enterprise today can survive if it is only focused on improving its operations. Projects are the engines that drive innovations from idea to commercialization. But projects are also the drivers that make organizations better, stronger, and more efficient. And since most organizations today accelerate toward a project-based world, shouldn’t companies ask themselves are they doing a better job than their competitors?

This situation presents a tremendous opportunity. The time has come to unleash the untapped potential that exists in projects. We believe that if managers and organizations will pay a greater attention to their project management practices, the rewards will be significant. If top executives will spend as much time on project management as they did on Six Sigma, they will make their organizations much stronger and more competitive.

PART 2: WHY MANAGING A PROJECT BY THE BOOK IS NOT ENOUGH

PART 3: WHAT IS MISSING IN TRADITIONAL PROJECT MANAGEMENT

PART 4: THE NEW ADAPTIVE PROJECT MANAGEMENT FRAMEWORK

Is Project Management a commodity or a craft?

Some days back I visited the Regional Transport Office of Bangalore North district, more commonly called RTO office. For those unfamiliar about my part of the world, RTO issues driving license if you pass their written test and driving test.

Bangalore, and I guess many of the cities in India, is teeming with driving schools. As the name would suggest, these folks teach you how to drive. In Bangalore and again, probably in other Indian cities, driving schools have, in a way, exceeded their brief. They also help you get the driving license. It is not uncommon to see a driving school agent chaperoning young would-be drivers around the RTO offices, filling up forms on their behalf, making them rehearse the driving rules and in general making them feel at-ease. With the passage of time, this has been stretched to such an extent that many would-be drivers go to a driving school, not to learn driving but to get a driving license!

Does this sound familiar? Rather very familiar? Isn’t this very similar to what is happening of PM education? You don’t see much of PM education happening around except maybe people getting coached to pass an exam. Traditional colleges and institutes do not offer PM as a course except maybe as an elective. The ones that do offer are not necessarily aligned to the practice.  Add to it the growth in number of PMI^® registered education providers who at the best provide only PMP^® exam prep programs.

As per PMI^®’s website an R.E.P. program has been designed to enhance the ongoing professional development of PMI^®’s members, those credentialed through PMI^® and others in the project management profession. But as time passed, a good number of them are now merely PMP^® exam coaching centers, with more following the suit. Some of them guarantee you passing the examination. A savvier few would even return your money back if you do not pass. Being a project management mentor, I have got requests for help in filling up in the PMP^® application from aspirants. (I feel like screaming at such requests!)

The conflict between credential being a commodity versus it being recognition of a craft (A craft is a skill, especially involving practical arts – Wikipedia) is a much debated and discussed topic in multiple forums. The jury is still out on this decision. But in the meanwhile, someone has to take serious look at PM education.

Coming back to my story, I had gone to the RTO for my daughter’s driving license. Even if she gets it, I would be really wary of handing her my car keys. I hope the powers-that-be in the industry do not share such apprehensions about a PMP^® certified project manager!

Eager to know if you would agree or disagree with me. Please do write.

Knowing your customer’s business.

I drive around in a Mahindra Scorpio shown here. It gives me unfair advantage on the roads in Bangalore where the right of way is based on the size of the vehicle! Lest you think so, this blog is not about the comforts of Scorpio or the horror called Bangalore traffic.

It so happened, some days back I rode in this SUV with my friend who is a mechanical engineer. As he got down, he looked back at the vehicle for a moment and said “Tell you what, my team designed the gear box for this SUV. Mahindra chose the design from a couple of prototypes we had made. Today, all the Scorpios in the country run on my gear box design.” Otherwise very restrained, my friend had to struggle to hide his sense of pride when he said that.

As you would have guessed, my friend does not work for Mahindra but his organization provides services to them, typically as projects.

This conversation set me into thinking. How many of us in our projects appreciate why the customer has entrusted us with the project? Or how many of us know where the project fits into the proverbial larger picture?

If you ask me, my answer would be “Not many”. Some if not most of, projects run on the classical iron triangle of scope, schedule and cost. The team gets the project with the requirements. It is executed hopefully in schedule and within costs and delivered back to the customer. Then you return to your home team and get reallocated to the next project in line. Taking further liberty, I would like to say that the PM is worried about on-time delivery and the team about sale-ability of the skills acquired through the project. And the twain sometime does not meet.

The basic question is should the project manager and the team know the customer’s business? Is this a nice to know or badly needed piece of information? Probably, the later.

Let me paint a few scenarios.

Is your project a part of mature well proven product? If yes, you can expect clear requirements but the customer would expect quick turn-around time.

Or, may be your project is a part of a brand new product/platform. You can expect uncertainty in requirements. (I am sure my friend in the above story would have faced a lot of this.) Don’t fret over frequent requirement changes.

Or is the customer meeting some legal compliance through your project. Expect very clear requirements but don’t get frustrated by thorough verification with a magnifying glass, almost nitpicking.

So, knowing the larger picture does help you in managing your project better.

If you become invisible and get into some of the project meetings, you will get to hear a lot “we and they” talk (or should I say “us versus them”, anyway). Like “They always change requirements”, “They do not know what they want”, “We are already overworked” etc. If you know the customer’s business, you will have less reason for the “we and they” talk.

I want to end this blog on a philosophical note. Inherent in the human heart is the desire to be of some use to somebody and to leave a legacy behind. Knowing the customer’s business fulfills this desire. Like “thousands of vehicles ply on the bridge that I worked on” or “every time you talk on this phone, my compression software kicks in”.  How do these statements compare with “we completed the project within 10% schedule variance but got beaten on cost escalation of 50%”?

Need I say more.  As usual, eager to hear your views and experiences. You could also vote at http://polls.linkedin.com/poll-results/95180/gamah.

Observations on the practice of estimation

I had heard this story long time back. There was this gentleman visiting a historical fort situated in a small village. He was walking his way to the fort but unaware of how far the place was. On the way, he saw an old man sitting on the steps of his house soaking the morning sun and asked him “Baba (loose translation: the revered), how long will it take to reach the fort?” The old man remained silent. Assuming the old man to be hard of hearing, the visitor continued his walk. In about two minutes, the old man called him back and told that it might take him forty minutes. Looking at the nonplussed and almost angry expression on the visitor’s face, the old man added “Son, unless I know your pace, how would I be sure of the time you would take?”

I wish the many of us in the project management community had the same patience and wisdom which the old man had in this story, when it comes to estimating and scheduling.

Through this blog I wanted to bring out some prevalent mistakes in estimation and scheduling.

Inherent inaccuracy: All the project managers (and their supervisors and customers) know that by its very definition every project is unique. The very first slide in any project management training course would say this. But probably this realization is only at the intellectual level. None probably wants to accept the fact that along with uniqueness comes uncertainty which in turn leads to inaccuracy in estimation. Moreover, this inaccuracy cannot be wished away till you are actually done with all the activities.

Single value certain estimates: Given the inaccuracy, shouldn’t the estimates have a range. Say 20 staff days plus minus 5. Or 10 staff days at 10% accuracy. But usually there is no range specified. You get to see only single and certain values.

Two, all the work elements get the same treatment. There is no distinction made on the uncertainty of the work element and thereby higher or lower tolerances in the estimates.

Same productivity for all resources: When resources are allocated to work elements it is assumed that all the resources have the same productivity. This simplifies duration estimation to division of work estimation by the number of resources. But unless the resource is a machine, you cannot assume same productivity. In fact, human beings are notorious for having different productivity at different times in the project. Needless to add, there are differences in productivity across humans too.

Progressive elaboration not considered: As project progresses, accuracy of the estimates is expected to improve. During the concept phase there would be a wide spread say -50% to +75%. During the design phase the spread would narrow further to say -35% to +50%. This implies that the project schedule gets re-baselined at the start of every phase if not more frequently. But this rarely happens. Once a schedule is base lined at concept stage, it is cast in stone. No re-estimation, no base lining.

Single project finish date: For all the reasons mentioned till now, should not schedule show the project finish date as a date with a range. Say 14-Aug-2010 plus minus 5 days.

But this is rarely the case.

Variations not anticipated: All schedules depict interconnected activities. Variation in one activity has a cascading impact on the schedule. Variation in a dependency outside the scope of your project may also impact your schedule. This is again a well known fact, which largely gets ignored. There is an entire new approach to scheduling called Critical Chain Project Management (Goldratt) which takes care of statistical variations and interdependencies. Even without buying the add-ons for CCPM to their existing scheduling software, project managers can use the concepts of feed buffer and project buffer put under the control of the project manager. But this is rarely done.

No Plan B: Most of the projects have foreseen risks. There is an elaborate risk register containing risk description, mitigation plan, owner etc. But when it comes to plan B, project managers behave like the proverbial ostrich with its head buried in sand. Foreseen risks with high exposure should prompt the project manager to be ready with plan B which would control the damage done by the risk. But one rarely gets to see plan B. Most of the contingency plans talk of communication and escalation like “inform the management” or “inform the customer” in place of a plan B.

So much said and done in the practice of estimations, I will be eager to know your view and experience regarding this topic.

Long before Hrithik Roshan[1] became their brand ambassador and set hearts “Dhak, Dhak, Go”, Hero Honda used to run an advertising campaign – “Fill it, shut it, forget it”. They were referring to the fuel economy of their bike which was claimed as 80 kilometres per litre. That’s why the line “Fill it …”

This popular ad-line popped up in my mind from nowhere, when a close colleague remarked that his project just goes on and on and on.  I began to wonder if the Hero Honda tag line “Fill it …” applied to project management too. I see more people looking at project management as a template filling game. The biggest and most talked about template we fill up is the risk management template. Fill it, save and close it and forget it seems to the practice of risk management.

My observation has been that using standard checklist people do prepare a list of risk or a risk register as described in PMBOK.  But the question is, do we move beyond risk identification and manage risks at all?  So in-spite of all the great intent with which register and plans are prepared, projects continue to fail.  In my view this is perhaps due to two problems

One, the risk register is not integrated with the rest of the project plan.

Two, the risk register remains a well intentioned document but there is hardly any follow up or in the PMBOK parlance, monitoring and control, of risks.

Problem one, is largely an issue of integrated planning. Revisiting the plan taking the risk as inputs is an area that needs improvement. It’s a good practice to show significant risk mitigation steps in the schedule as activities. This ensures that the mitigation plans have an owner and a date.

For example, if the lack of expertise in technology is identified as a risk condition, the corresponding mitigation response would be training the team. One or multiple activities related to training should be there in the project schedule. Taking the same example further, if this training involves hiring a vendor’s services, one should allocate a cost to this which in all probability may consume the reserves or contingency fund.

It is also possible that training once conducted, may not reduce the risk exposure and one will now need a contingency plan or plan B to reduce the impact of this risk to the objectives. For example, hiring expert services on short term contract could be your plan B.

Problem two is the ongoing monitoring and controlling of risk register. It is not sufficient that risks be documented during planning alone. The on-going effort and not just intent to monitor and control, is critical and not doing this is as good no risk management at all.  Remember a risk never closes completely, it just retires. At the same time, a new risk could be just lurking around the corner.

Apart from this, it is possible that the risk exposure of active risks changes that in turn may impact the overall project objective.

Identifying risk triggers is not only useful for monitoring but also assists the manager in defining the appropriate mitigation steps. Risk trigger plays an important role in alerting the manager if a risk is likely to occur. If you are not watching out for the trigger and looking at the actual risk event instead, you may not be left with much leeway to act.

Like they say, chance only favors a prepared mind, just filling up the risk register template and shutting it is not good enough or else we forget about project success.

The maturity of business organizations when it comes to management of IT projects is an area of concern for many CIOs. CIOs lack the visibility they need into project performance, and do not know the magnitude of project delays or the reasons for these delays. Most IT projects fail or are abandoned half-way not due to technical reasons, but largely because of management issues which start from the project selection process itself. There is a need for all to understand that management of IT projects as a service provider (an IT consulting and services company) is very different from managing an IT project as a business organization.

One of the key differences is the approach towards management of IT projects. While the user organization focuses more on the project’s outcome, the service provider’s focus is on project delivery to specifications. The distinction between these two from a project management perspective is not clear, nor is it clarified by industry associations or proponents of project management.
 
There is a need to look at the entire project lifecycle from a business perspective for effective management of IT projects. Aligning the project to business objectives and defining the project’s success criteria early in the lifecycle is a critical aspect. You should look at the success criteria beyond just the efficiency metrics of being on time and within budget. In fact, these are success criteria for the consulting, vendor and contractor community. The user organization should focus more on the business benefits, and not on efficiency of project execution. We are not suggesting that efficiency metrics be ignored, but that they are the responsibility of the contractor (or consultant), and that their impact on the business needs to be measured and controlled.

There is a clear need to distinguish between the various approaches adopted by business organizations or user organizations of IT when it comes to management of IT projects. Moving to a program management process approach could perhaps assist the CIOs and IT managers to appreciate this difference and improve success. Given that most projects have a business case, once the implementation is done, it is important to check whether you have achieved the business objectives. This approach is generally not followed by Indian organizations, so CIOs need to focus on this.

IT project management has moved from being a tactical discipline, and now involves the integrated discipline of program and portfolio management. There is a need to make the IT leaders, the CIOs, aware about this. The use of the traditional development lifecycles (such as SDLC) approach to the management of IT projects needs to change, at least for the user organization.

The future is big

The term ‘project management’ is only a few decades old. Of course many projects were managed before this science was ‘invented’,  and nobody had identified a distinctive need for a management process, still less had they decided what that process should be.

Fact is there were more projects managed before modern ‘Project Management’ was developed than have been managed since. And even today, there are more projects being managed with no help from this science than with it. It could be said, therefore, that its influence up to now has been very small but its potential influence in the future is huge.

One researcher writes in a paper, “Of the 34 important new management approaches and techniques invented since 1960, only 15 were still in use at all by 1995. Their life from invention, through peak use to disappearance, was seldom more than ten years”.

I believe that project management will survive in the long term for two reasons.

1.    It is essentially simple and

2.    It is capable of extremely wide application

The techniques which we now call project management have all been identified and developed over the last forty years. Collectively they are now a proper science, carried out by people who know how to apply it. It is a science, in that it can link cause and effect; it can be taught and learnt.

One way to know the future is to look at trends and if zero people used PM as science in 1960, then it has increased since then and we can safely say its application will continue to increase. Here are some observations to light our path:

•    B K Mundhara, Chairman of Simplex projects, said that we will have more project managers than MBAs in this country

•    In twenty years time, due to the inevitable inertia of human systems, project management has only achieved half its possible volume of application

•    In twenty years there will be 120 project managers for every one there is now – that’s quoting Dr. Martin Barnes in 2002 at a Berlin PM conference

So what will the future look like?

Application of PM will become broader. The application of PM will not just be restricted to physical enterprises like buildings and new products – it will also cover non-physical endeavors like winning an election or a court case, like merging two businesses or bringing together two people in marriage; it could even include introducing the market economy into a former communist state of a country.

Focus of PM application will shift to understanding the whole or towards ‘super projects’, which we recognize today as a programs or part of a portfolio. Every project is carried out for a commercial organization and is a sub-set to that of achieving its corporate goals. Even in a democratic government every project is a sub-project to the project of securing re-election next time. Every project we undertake as individuals is a sub-project linked to the project of securing our own happiness – whether short, medium or long term. We will start looking at managing the super projects too. These super projects will either resemble a program or a portfolio and focus will be on Benefit and Value Management.

Changes in the Science and Tools of Project Management: Both the hard as well as soft techniques of PM are changing and developing fast and can be expected to charge the velocity of change.

The battle of hard sciences

A project is about a group of people collaborating towards a (presumably) common objective. The actual management is primarily about communication and visibility of progress/work that lies ahead for the project members. Directing the executing team presents a novelty when the project and team member competencies are developed on the project itself.

Hard Sciences have evolved from network analysis and critical path method, to advanced heuristics for resource leveling and algorithms etc. But these never quite caught the fancy of real project managers. Also these hard sciences were being pursued by people who found this sort of technical progress fascinating and believed in its illusionary potential.

We continue to produce these network diagrams, Gantt charts etc; but the focus today is on sharing this data. I believe that real PMs prefer to use simple excel sheets rather than any software tools to produce the schedules. I also contend that there is still a future for such hard sciences like scheduling analysis. Hard techniques need to be learned insofar they form the foundation for visibility for project progress (e.g. in cases where details in a plan are not understood by the real PMs. Take a 2500 cr. power project oversight and macro planning achieved with 140 line items).

On the collaboration front, we see a lot of action; it’s more like a virtual communities spontaneously coming together around a project or a group of similar projects. So we have PMs googling, going to social networking sites to find answers to their issues, relying on peers to assist in sourcing people, vendors, etc.

We see project intranets being built and then integrated to social networks for collective knowledge building around issue and risk management.  This is supported by the fact many of the PM tools are adding Content Management Systems to their application suites. Is this a step in the right direction? I don’t know but things seem to developing more in line of what Gartner predicted.

Other organizational endeavors point towards creating predictable environments by way of instilling systems and process culture (e.g. ISO, CMM). We see the continuing labor on illusionary process framework definitions, but real PMs or PgMs continue to work without these.  The way I see it, these efforts have not lead us towards sound Risk Management practices; all the same, we can discern a future for this science coming up. I still find people getting upset if project plans are completely changed mid course but such is reality.

PMOs acting as a central base continue to be a real support for PM acceleration and maturity. I predict that supporting PMs, rather than playing watchmen to the governance team, will lead the battle front by taking more responsibilities as teams become more virtual. PMO reengineering will finally become a reality as PMOs supported by effective integrated applications get real estimations, measurement and mentoring to the Project environment.

All in all, development of the discipline with continue – Program, portfolio, PMO, Change Mgmt, Dash-boarding (people particularly fancy the dancing traffic lights), management by projects, etc.  But let’s keep in mind none of this is absolutely new.

On the softer side

I feel the future is more about certifications, systems and methodologies taking a back seat in order to facilitate core customer needs through involvement and communication, first and foremost.

To this end we see a merger of skills taking place in the marketplace i.e. PM/BA/EA. We are seeing a shift from certification to competency and confidence building. This trend follows the rapidly closing gap between Project Leaders and Project Managers.

We may soon see knowledge profiling of PMs being used to determine the right fit of project profile to his or her profile. My own team created an intelligent tool for learning which gave our trainers data on weak areas of the learners benchmarked with others, but we soon found out that nobody seems to using the data and info available.

We would also like to see the so called sr. leadership team finally deciding to go back to the classroom and align themselves to the PM Way of Working.

Conclusion

So if we practitioners need to remain a part of the future, we need to ensure that the science is continuously developed and at the same time so-called best practices are tested rigorously in order be really useful to real PMs. There should be real knowledge sharing happening.