When the IT organization reported directly to the plant manager, the business objectives were being met satisfactorily as determined by the plant management. However, the corporate office was concerned that IT development was not being done in accordance with the corporate standards, so they decided to come in and take over the department. In doing so, the corporate office imposed so many new restrictions and administrative processes that the direct support of the plant suffered.

The culture of the IT workforce at the plant was geared to provide total support to the plant—no matter what it took to get the job done. When corporate took over, the objectives changed, as more focus was placed on meeting the corporate objectives instead of the plant objectives. This created conflict that has had a huge impact on the ability of the plant IT group to meet the plant’s IT requirements. The structure and processes changed, which decreased IT’s ability to respond in an expedient manner to client needs.

When the IT organization reported to the plant management, the organization was very organic. Projects were identified and completed with great cooperation between IT and the plant clients. Once corporate took over IT, the organization slowly morphed into a very mechanical organization. Three separate silos were developed; these reported up to three different corporate managers. Cooperation became less apparent within the IT organization, which totally impacted the ability to deliver products to the plant clients. The organic model is a much better organizational structure than what the mechanical one has proven to be.

Within the current mechanical structure, it is difficult to get projects coordinated within IT. No one seems to take ownership. Each group is focused on meeting its own objectives regardless of how it affects overall organizational effectiveness. Performance has suffered, and ability to manage projects has suffered.

Some people have a wide range of skills to establish a good, natural, spontaneous, positive, and friendly relationship with other people. Some people don’t. If you do, no doubt it’s a good beginning, but it’s definitely not enough. If you don’t, you can still be a brilliant professional. Yes, you can be a good project manager even if you are not the most popular person at the party.

It is a good thing to have natural social and emotional skills, but there are two or three things worth remembering:

Everybody is different. This statement might seem obvious but is very easy to forget. We have to adapt and fine-tune our behavior to successfully handle different individuals.

You can learn new skills or improve those you already have if you really want to. Before beginning the long way of improvement, though, ask yourself if you really need to and whether you want to devote energy to such an activity.

As a rule of thumb, friends and colleagues are two different groups of people. If your company has chosen you to be a project manager, they expect you to perform that role in a professional manner, not just to be a friendly boss.

Working with people is not easy—I can’t emphasize this enough. Working with people is part of our job description, just as writing emails or attending meetings. It took a long time until I finally realized that. Dealing with a tight schedule, a quality problem, or a difficult person is part of our jobs. Therefore, if I do my best to work on schedule, within a set budget and meeting the quality standards, I must do my best when dealing with people. Even more, working with people is a paramount part of our work. My personal experience is that if I really think about the goals of the project, I tend to deal with difficult people in a professional manner—not focusing on our differences—and that is very helpful and effective.

I work in a good company, and I love the work I do there. My company has been growing a lot, putting much effort into expansion, technical improvement, and reviewing operational procedures. I was promoted to engineering manager and had to perform many functions of a hidden PMO—and then I realized that there was still room for improvement. I learned about project management and PMBOK guidelines and convinced senior management to design and implement a tailored methodology to help us improve. Senior management understood that that was the only way to succeed in the great challenges we have to achieve in the near future and understood that adopting a project management approach was the next step in the process of growing and updating the company. Luckily, the initiative was fully supported by top management, and we really started a soft cultural change.

That was easier to say than to do. The first year was dedicated to learning project management and analyzing our current situation; the second year was dedicated to designing, communicating, and training users in the new methodology. The third year is a year of consolidation, and the fourth year allows us to fine-tune methodology from real learning experiences. I truly believe that deep cultural changes are always slow and soft, nondramatic: a deep revolution in an almost imperceptible manner. There are days when I feel we are not going to succeed, but I still lead the process in a professional way. On the other hand, some days I feel we are on the right path. Every day I am convinced that this is the correct and only way to manage projects in a complex organization.

In my opinion, the more long term a cultural change is, the slower it is. Speeding it up could almost be counterproductive.

As a collateral effect (once you begin to analyze your processes, you find that more things than you thought a priori need to be improved!), we have begun similar improvement initiatives for related areas, such as the purchasing and investment control areas. We have found synergies in all these processes, and we are using a similar approach to review them. Some of the processes used for project management are also useful there. The seed of cultural change is growing!

I hope to share my thoughts and wisdom on all things project management and gain even more insights and wisdom in return from readers. My job is to help people create a vision and plan for implementing change, then facilitate the successful implementation of that change. My focus is on “what’s in it” for the impacted parties, then working to create an environment that promotes a smooth transition.

I gave a presentation to a group of people who made up the governance stakeholders of a newly initiated, multiagency, federally funded project. The presentation was developed to be generic and geared towards a large, diverse audience that may include a mix of sponsors and project managers from different organizations and different projects. There was an unforeseen advantage to giving a general sponsorship presentation to a specific group.

The discussion at the presentation was among individuals with a vested interest in the governance of the upcoming project. They were able to review the definitions, responsibilities, and recommendations within the presentation and have candid conversations about the needs for this project. It helped open people’s minds, and the discussion, about who should be invited on the steering committee and how the sponsors could work together to complement each other and acknowledge competing interests in the project, and it helped give light to what they will need when selecting a project manager to help the project succeed. Because there was so much interest and discussion, the downside was I had to cut the presentation short because we ran out of time, but given the work and discussion that did happen, I am okay with that.

The point is to say that because sponsorship was presented in a way that promoted discussion of the concepts with all governing stakeholders, the group was able to discuss their needs rather than being told what they needed to do. The discussion validated that they understood the roles of the sponsors and steering committee and how they could set the project up for success.

I suggest these commitment strategies for each and every project manager:

•  Understand the sponsor’s expectations, goals, and objectives of the project.

•  Plan frequent, yet brief one-on-one discussions with the sponsor.

•  Be the sponsor’s trusted source of information.

•  Make sure that messages sent are received as expected.

•  Be clear in making known what he or she needs from the sponsor.

Executive involvement in project reviews. The PMO called for a meeting to run a project review. That meeting was a great opportunity for the executives to know more details about the project, and to understand much better the project manager difficulties and lack of skills in order to improve project management in the organization.

Project portfolio training for all the project stakeholders. In that training I was helped by the PMO team to gather information about the projects in the bank portfolio. In that way I was able to understand the level of knowledge executives had about the projects they sponsored in the organization.

Half-day session training for business managers. In that session I explained the concept of project sponsorship, its meaning, and implications to all business managers. I spoke the language management understands.

General manager coaching in project sponsorship. It took some time and effort, but the general manager finally came to appreciate the value added at the end of the project. He understood the role of sponsor very well, and it was one of the reasons for project success.

I sat anxiously in the PMO director’s office waiting to present my proposal for an organizational portfolio management process implementation. I had spent the previous several months drafting the process and holding reviews with several key company stakeholders. My homework was done, and I knew I would hit this one out of the park.

The presentation spanned the next 30 minutes. After what seemed like an eternity of silence had passed, but in reality was probably only ten seconds, the PMO director finally offered his verdict. “Am I the only one that has major heartburn with this process?” My heart sank as I wondered what I could have possibly forgotten to include. He continued, “This process will never work here, as you are proposing to ask one vice president to give up resources (both human and financial) to another vice president, to his department’s detriment.”

To date, I have implemented portfolio management processes across several organizations with varying degrees of success. In theory, the premise sounds very appealing to an organization—align all the organization’s projects and other work with its strategy, allocate resources accordingly, and deliver on the strategy. However, in practice it is usually quite different. Introducing portfolio management processes into an organization, even those with very mature project management processes, is a monumental undertaking, to say the least. If you’ll pardon the cliché, it is akin to steering the Titanic with a soup spoon.

The challenge that I have encountered in every implementation of portfolio management thus far is that a gap seems to exist between the promise of portfolio management and the practice of modern business management. This was evident in the PMO director’s comments above. Modern management practice rewards individual managers, especially executives, for their particular department’s performance. Portfolio management requires these same managers and executives to give up a portion of their slice of the pie for the good of the entire organization, yet their performance is still being assessed based on departmental performance. Can you identify anything wrong with this picture?

This seemingly small gap is a primary reason portfolio management initiatives fail in organizations. The development of portfolio management processes in organizations is relatively simple and straightforward. As with most things in management, the challenge lies in the human element. For an organization to reap the benefits of what portfolio management has to offer, human behavior, motivators, and agendas must be considered.

Very rarely is an organization structured into a single pool of resources. The vast majority are still structured as numerous departments dispersed across the enterprise, ultimately rolling up into a single entity known as “the company.” A company’s budget is typically distributed across departments based on numerous factors such as department size, profitability, and forecasted growth. You are fortunate if you are in one of the few organizations that actually align operational and project work with company strategy and even more fortunate if the organization’s annual budget is distributed according to that strategy. So, what are we to do?

The answer is simple to state but incredibly difficult to implement. The way organizations are designed must be revisited. Simply implementing portfolio management processes, as defined by PMI, is not enough. Executive and managerial accountability and reward systems must be thought through in advance and built into the system. In his book The Future of Management (2007), Gary Hamel introduces us to the Emerging Business Opportunities (EBO) process developed at IBM. Launched in 2000, the EBO process rapidly evolved into a comprehensive system for identifying, staffing, funding, and tracking new business initiatives across IBM (Hamel and Breen 2007). In the program’s first five years, IBM launched 25 new businesses. While this example is not directly applicable to portfolio management, it is a great example of promoting executive collaboration and partnership.

I am now well into another portfolio management process development and implementation. And, as usual, the organization in question is eager to run while it is still learning to walk. While eagerness and willingness are admirable traits, if all aspects of process implementation are not considered, they can be incredibly haphazard. (Irwin 2010)

The subject of this essay is an attempt to answer the question of why organizations consistently attempt to do too many internal projects at one time. This situation is an important problem because the attempt to simultaneously achieve many projects results in delaying all those projects as well as causing a less-than-optimal employment of project resources. That is, attempting to do too many projects causes delay and costs money. This is not an isolated problem occurring in only a few organizations. No, it is a widespread problem occurring in many business organizations. This is also not an unrecognized problem, one that the business managers would attend to if only they were aware of it. No, it is usually a quite well-recognized problem, with managers often asking what can be done to eliminate that problem. Nor is it a problem without solution. There are some very good solutions to this situation that are quite well known, that have been known for many years. The solutions are reasonable and rational, often recommended by project management consultants, and usually received quite favorably by business executives. So, this is a problem which is important, widespread, well known, and with well-known solutions that executives usually accept. However, this problem is rarely solved. This essay is an attempt to understand some reasons why this situation continues to exist and why a resolution continues to elude us.

This situation as described fits into Barbara Tuchman’s definition of folly. According to Tuchman, folly exists when people know there is a problem, they know there are choices to solve that problem, they know that the choice they are following will not solve the problem, yet they continue to follow that choice, which they are quite aware is wrong. She cites many instances of this situation occurring throughout world history. So, organizational folly is not a new and unique phenomenon, but rather it has a rich and glorious history. To understand how such folly develops and persists, we need to examine the organizational dynamics that guide people’s behavior and sentiment to favor the status quo over a problem solution.

The basic outline of our analysis will be that organizations develop procedures to solve problems early on in their existence. These procedures become second nature to organizational members and are passed on from generation to generation. They probably made sense when they were originally developed, but as things change the continued application of old procedures begins to cause problems. The solution to the problems is usually in the abandonment of old procedures and the substitution of new ones. However, the old procedures become so ingrained in organizational groupthink that abandoning these procedures becomes a very difficult process of organizational change. Some organizations attempt to change, but the process becomes so long and so arduous that it seems to many that the benefits to be gained are far outweighed by the costs required to gain them. Thus, the change effort, like most change efforts, fails and the status quo prevails.

Organizations have too many projects because the methods for choosing, staffing, and managing projects are not based on best practices but are rather procedures that evolved from times past. These methods normally evolved from standard procedures used in departmental organizations. However, projects do not fit into departmental structures but are rather temporary and cross-departmental endeavors. In short, projects are the antithesis of departmental organization.

As a result of the evolution of methods, the procedures used to choose, staff, and manage projects are exactly wrong. Now, an organization can “muddle through” using improper procedures, and most do until there is some massive failure or a concerted effort by the organization’s management to install better practices.

To begin, methods for choosing projects are normally not well defined. Now, this is not true for capital projects, where there are massive amounts of money being spent. But it is true for so-called internal projects, such as systems upgrades, new product development, or increasing customer service. For capital projects, the biggest constraint is money, and so this is well analyzed. For internal projects, that constraint is normally other types of resources—mostly people. In the past, most projects could be accomplished pretty much in one department. People within departments would decide what needed to be done and allocate their people to that project. The largest department had the most people and usually had the most projects going. Projects were usually defined as being from a particular department and thus assumed to be for the benefit of that department.

Of course, there were always more good ideas than there were people to go around. When people had a good idea, they tended to get a project going without regard to other projects that were in process. To get a new project going, you need to steal people from current ongoing projects, and this was done. In order to do more with less, people were told to work part-time on a variety of projects, instead of full-time all on one project. In this way the department could have many projects going out on time, and thus rising status and prestige.

Associating projects with departments resulted in many negative consequences as projects became more companywide and thus interdepartmental. Projects, which were often known as “something they’re doing over in engineering” (or wherever) would have difficulty attracting people from other departments. First, other department managers would want to keep people for their own projects. Second, whatever it is they’re doing over in engineering can’t be that important. This is true by definition for all those people who are not part of the engineering (or whatever) department. Given this setup, people from other departments would be provided to engineering only begrudgingly, and they would certainly not be the most capable people.

An additional problem arose because the estimate of the time required to complete the project was usually optimistic. Now, the original estimates may have been valid, if all the people on the project were from the same department. These are people who know each other, who know each other’s technical strengths, and they are used to working together. As projects became more interdisciplinary, more time was needed to get those people on the project to gel as a working team. This time for team development was normally not considered and thus was not factored into time estimates. As a result, projects began to take much longer than was expected.

In addition, project managers were accidental. Many times, people were chosen to be project manager because they knew the most about the problem or the technology being used. That is, people were chosen not because they had particular management skill, but because they had technical skill. This resulted in the phenomenon of the accidental project manager. Accidental project managers tended to focus on the technology rather than on the people who were on the project. As a result, very little emphasis was put on basic project management tasks such as developing a work breakdown structure (we will know what to do when we get there), developing a project plan (plan is just a four-letter word), and developing the project team (because we’ve got real work to do). This lack of attention to the management of the project contributed to further project delays as well as a general decrease in project outcome quality, often requiring extensive rework. As a result, projects began to take even more time than they “should have.”

The process outlined above results in a reinforcing spiral of project proliferation. First, too many projects are started. This results in people working on a variety of projects, which means each one of those projects takes longer than it “should.” The right people are not put onto the project, and this adds more delay to each project. Given that projects have become more interdepartmental, more time is necessary for team development, which adds even more time to project durations. Poor project management contributes further delay. Of course, while all these projects are taking so much time, people come up with new ideas for things that need to be done. And so, they add those projects into the mix, which spreads people even thinner, which delays all projects some more, such that those that should have been done by now are not done, so that the number of projects continues to increase, seemingly without end.

Methods to stop this spiral are numerous and well known. However, they are not easy. Eliminating this problem requires a coordinated, comprehensive, and long-term program design to eliminate old habits and teach new ones. The components in such a program are given below.

First, the process for selecting projects needs to become more formalized, as well as centralized. Most such processes involve a management committee taking over the process of project selection. This committee develops criteria for project selection such that all projects selected contribute to the achievement of organizational strategy. The committee also develops an estimate of the resources available for projects so that the number of projects selected is within the means of the organization to complete by the time they are needed. This committee starts by applying their criteria to the current situation, thus decreasing the current number of projects, which is no easy task.

After project selection, the executive committee sets priorities for the scheduling of projects. That is, instead of attempting to do three projects at once, for example, projects are scheduled in series such that a lower-priority project is not begun until the higher-priority project is completed. Doing projects in series helps to speed project completion and thus contribute to eliminating project backlog.

Next, the executive committee appoints a project sponsor. This is important, because no difficult project ever succeeds in a hierarchical organization unless there is someone at the top who really wants the project results. The project sponsor then works with the project manager and departmental managers to ensure proper project staffing. Proper staffing means that people working on projects are working on only one at a time. It also means that core team members are committed to the project from the beginning to the end and that departmental managers ensure such team members’ participation for the project duration.

Finally, the executive committee ensures that a competent project manager is appointed. This means that the person appointed will no longer be selected based solely on technical knowledge but rather based on training and ability to manage projects in the business organization. In addition, the executive committee ensures that all project members are trained in project management techniques in order to maximize their performance in project settings. Working on projects is much different from working in departments, and project performance increases when people are trained in these differences.

As previously mentioned, the ideas outlined above are quite reasonable and rational and are usually accepted by business organizations. The problem usually begins in the implementation of the new ideas. Such implementation requires a long-term coordinated effort to change behavior in the organization. It is well known that most organizational change efforts fail. Organizations are not set up to do something different. Rather, organizational beliefs, rewards, systems, and procedures are designed to maintain the status quo. Modifying this organizational reality is a long and arduous task fraught with delay, disappointment, and upset. At some point, those guiding the change will determine that the costs of the change are more than the benefits of the prize, and thus the effort is abandoned, and the status quo remains. An effort to change the number of projects will encounter many of the same difficulties.

First, who will lead this effort? Establishing a new order of things requires a long-term commitment from the very top of the organization. As previously mentioned, most organizational change efforts fail. The effort to reduce the number of projects will require a long-time commitment to a process that will most likely fail. And most organizational members, particularly those at the top, understand that a person is defined much more by their failures than by their successes. That is, they know that successes are soon forgotten while failures are long remembered. Thus, it is often difficult to find powerful organizational members who feel strongly enough about the “too many projects problem” to risk damaging their careers. However, without this powerful commitment and support, the effort will be doomed to failure from the beginning.

Next, there is a matter of the executive committee. It is usually assumed that this group will be a voting committee so that a consensus can be reached regarding project acceptance and scheduling criteria. This normally means that an executive will have to yield power that she has traditionally had and defer to the consensus of the group. This will be very difficult to achieve. First, people in executive positions usually want to maintain or increase their power so that they can have more influence on the direction of the organization. Second, it is extremely difficult to take something away from someone once he has become accustomed to having it. Therefore, one should expect that many rational-sounding arguments will be dismissed in order to maintain the power status quo.

Despite this resistance, it is true that many times these committees are formed. However, organizational reality is that one particular department will be dominant in terms of budget, power, and prestige, and so the director of this department can be expected to lobby for more say in project selection. When this happens, it usually means that the project selected will be more heavily weighted toward the more powerful department, just like it was before.

After this executive committee is formed, they will find that developing criteria for project selection is no easy task. If the criteria are developed, they will find that applying those criteria to eliminate current projects is almost impossible. People will easily agree that projects should be eliminated, unless it is a project that they favor. Good, rational reasons can always be found for not eliminating some particular project, particularly if that project is favored by the more powerful department. It will be argued, for example, that a particular project is “important to the future of the company” and thus cannot possibly be eliminated. If rational arguments cannot hold sway, bureaucratic arguments will abound. It will be argued, for example, that “we spent so much money on this project already—stopping it now would be throwing that money away. Besides, we’ve got the team up and running and will never get them back if we stop.” If neither rational nor bureaucratic reasons hold sway, political deals will be struck (“I’ll vote for yours if you vote for mine”). In the end, the review of current projects will reveal that none of them can be eliminated, just like it was before.

Since no project can be eliminated, the next step is usually an attempt at project prioritization so that projects can be scheduled to be done in series rather than parallel. There are several well-known techniques for rationally establishing project priorities. However, these techniques can be gamed and even sabotaged. The same arguments against eliminating projects will resurface, and the politics will intensify. Not surprisingly, high-priority projects will be those favored by the most powerful department, just like it was before.

Even if there is agreement that certain projects should be stopped, that does not mean that work will actually be halted. There are several well-known examples in which a CEO has ordered work on a particular project to stop, but still the work continued. Anyone who has been in a bureaucracy for any amount of time quickly understands that there are ways to get things done that never appear on any budget or time sheet. I have personally been in several organizations where it seems that every department had a “secret project” going on. So even though there may be formal agreement that a project will be stopped, the work goes on, just like it did before.

Despite the best efforts to prioritize projects, crisis projects will arise, and attending to these tends to ruin whatever priorities were agreed upon. For example, suppose we had three projects, A, B, and C, to be done in that order. One can expect the people who prefer project C to be complaining from the onset. Now suppose that during the execution of project A there is some crisis that requires everyone’s attention. When this is done, project C will be even further delayed. The people who prefer project C will complain that if things had been done the old way, then at least something would have gotten started. Now they feel that they may be delayed indefinitely. Experiences like these give people even more reasons to continue to work on projects even though they agreed to the priority system.

Of course, while this is happening, project team members will be aware of the confused situation. On the one hand, they’ll be told to delay work on certain projects, while on the other hand they will be told to continue. Team members will start to complain that the new priorities scheme is just another “flavor of the month” that will soon pass. This is because most organizational members have seen attempts at change before. They’ve seen the change announced, they’ve seen confusion concerning the change, they’ve seen lip service given to the change, and they’ve seen it fade away. To protect themselves they will work on whatever project their departmental manager tells them to work on, just like it was before.

While all this is happening, project staffing does not get any better because everyone is still just as busy. The chorus of complaints rises, and organizational members chafe under the stress of change and long for the “good old days.” Perhaps at this time the person leading the change effort wavers a bit, a signal that the end is near. At this point the change effort loses steam and dies of its own weight. People decide that the benefits to be gained from getting projects done better and faster are not worth the amount of pain inflicted on the organization. So, people revert to “muddling through,” just like it was before.

On the other hand, there are some valid reasons for continuing to attempt too many projects. First, the choice of which project to do first may not be clear. When this is the case, it may be best to start several projects at one time and then see which one looks to be the most promising. Second, the use of so much rigor could bring on rigor mortis. A famous example of this occurred at the Ford Motor Company, where following a very rigorous project selection technique yielded the Edsel, a famous failure. The management team felt burned by this experience and was hesitant about developing new automobile models. Luckily for them, a group of engineers ignored management dictates, worked on a “secret project” out of management view, and produced the Ford Mustang, a famous success that is still produced today. Finally, it’s much more fun to work on projects than to work on selecting them. That is, the process of meeting, discussing, voting, and cajoling is pretty dull stuff. In addition, the amount of time spent doing all that might well be better spent actually working on projects. People who work on projects have a bias toward action, not talk.

In this essay it has been argued that in a departmental organization, doing too many projects seems to be the natural order of things for a number of reasons. It was further argued that the cost of the organizational turmoil and the pain required to change that natural order is usually judged to be greater than the benefits to be gained from the change. In any organization, there are powerful forces at work to maintain the status quo.

It would seem that the best way to have an organization that does not do too many projects is to have the organization establish project selection committees when the organization is first established. In that way, techniques required to limit the number of projects are ingrained in organizational systems and assumptions. That is, doing the right number of projects is established as the status quo. When this is the case, the people who are attracted to that organization are those who are comfortable working under that type of system. In that case, any move toward attempting to do too many projects would be resisted, as it would be a change in the status quo.

However, for the typical departmental organization, this is not the case. Attempting to do too many projects is the norm, and so it shall remain. Far as we know from so many years ago, that unless there is severe pain, that “mankind are more disposed to suffer, while evils are sufferable, than to right themselves by abolishing the forms to which they are accustomed” (Thomas Jefferson).

The fast-changing VUCA (volatile, uncertain, complex, ambiguous) world is forcing leaders to consider different approaches to running their organisations. In my interactions with business leaders from various sectors around the world, I see an increasing need for a focus on value.

The mention of the word “value” usually causes heads to nod as if a collective unspoken understanding of the meaning of the word exists. Not so! There is a great perception on what value is with a default meaning revolving around monetary aspects. There are also formulae circulating that support this notion.

The term “value” in any organisation needs to be determined, defined, and used in statements that set the cultural tone and working style of the organisation. To me this can revolve around four elements:

•  Value to customers

•  Value to staff and brand

•  Strategic value

•  Monetary value

Within those elements four types of value need to be considered so that an organisation can leverage the maximum value at any given stage. These value types are:

•  Inherent

•  Added

•  Innovative

•  Now

The four value elements together with the four value types allow a comprehensive approach to be applied that increases value creation but also value capture. The integrated model can be applied to both opex [operational expenditure] and capex [capital expenditure] investments which allows the balancing of risk with opportunity. Today I believe that the creation of value that is realized quickly is the differentiator between organisations that are progressive and agile compared to those that are risk averse and slow. Creation and capture of value should be top of the agenda in boardrooms, executive tables and, I would suggest, EPMO offices. The notion of value being just a monetary aspect is so out of trend!

There is plenty of evidence that strategies and strategic plans fail due to a variety of reasons. There is evidence also that the implementation activity fails at rates of around 30 percent causing enormous wastage of time, money, and resources. This can create significant negative reaction on the brand perception. A focus on value creation is one thing, but if there is no integration or alignment with value capture, then great intentions associated with strategic plans are just that—intentions!

To me, organizational leaders need to shift their focus to a wider value mind-set, one that is well developed, integrated, and understood by all in an organisation. It’s not just another set of mid-management processes that run the risk of choking the organisation through bureaucracy, compliance, or slow decision making. I believe that leaders must show the way and encourage all to simplify their way of doing business. However, this can lead to chaos if not guided by an overarching philosophy. That philosophy can be adoption of the “3Ps to Success” where purpose, people, and performance are focused upon, developed, communicated, and embedded as part of the organisational culture. This focus will allow leaders and managers to free up the organisation by the removal of processes that are not aligned to, or supportive of, the value management approach sought.

For a value management shift to be sustainable, it requires some form of framework that allows for value strategy, planning, engineering, delivery, and capture to be governed and deployed in a manner that is efficient, effective, and easily understood by all involved. This framework applies at the commencement of value creation dialogue and advances through the phases of implementation so that value is confirmed. This would be measured against the achievement of one or more business objectives.

The value management framework should include classic tools and techniques such as value planning, value engineering, and earned value management. Examples can be option analysis, cost, time and quality trade-offs, and benefits realisation in Programme of Work delivery.

The next few years will demonstrate and introduce change in areas of geo-politics, technology, environmental, and social well-being that will likely have considerable impact on all organisations. Leaders that can guide their people towards a value orientated focus and culture that uses the philosophy of the “3Ps to Success” will be those that will boost their organisational performance. The American scientist James Bryant Conant once said, “Behold the turtle. He makes progress only when he sticks his neck out.” This should be a rallying cry for all, including those in the portfolio, program, and project management profession.

… often make engagement decisions that include factors other than just monetary based reward systems. Social networking and informal referrals will lead much of this activity. For example, you might get a group of young skilled professionals that are geographically spread networking via Facebook and asking, “Is this organisation cool?” or, “Can we contract for 3-4 months to raise some cash for our next trip?” These people are “global gypsies.”

To attract these skilled “global gypsies” and persuade them to set up camp and stay a while requires organisations to make themselves the most attractive they can be to those gypsies. This is more than branding or marketing. The attraction aspects need to be multifaceted. They need to clearly demonstrate elements of excitement and empowerment, developmental opportunities, career path options, and entrepreneurial extras. This will also mean budgeting for more elaborate development, reward, and retention programs that go beyond traditional bonus-type systems. The bottom line for organisations is twofold: Focus on attracting and developing the right people as well as balancing your structures and systems for better resource empowerment. This will create an organisation that can sustainably achieve higher performance.

Why. Project managers are advised to care about strategic thinking because projects serve the purpose of either operational excellence or strategic excellence. Especially for those projects that serve the purpose of executing the organization’s strategy, project managers (or program managers) need to adapt project-level decisions to the relatively higher-order strategic decisions. Too many individuals have been told, “You need to be more strategic …. You need to think strategically.” This is an ambiguous statement, and they need to better understand what that means. Just like no one would be happy to be called an incompetent project manager, no one would be happy to be labeled an incompetent strategic thinker. Especially, program managers and portfolio managers are closer to the development of strategy. Organizations have good strategy and bad strategy. Good strategic thinking is more likely to deliver good strategy.

What. Strategic thinking is an individual competency. Strategic thinking is a complement to leadership. It means seeing the bigger picture and linking all actions, tasks, and projects so they contribute to fulfilling strategic goals.

How. Develop microskills: curiosity, high-quality questions, open mental stance, nonlinear imagination. Pay attention to words spoken, documented statements, and actions undertaken by upper management. Find ways to support them.

Why. Organizations invest a lot of time and thought into their own brand. In many cases, their brand is considered their most important asset. Personal branding is applying that idea to the individual. Project managers need to care about personal branding because it is up to them to manage their own careers.

What. Personal branding is different than reputation. What are the promises you make to others? What is your thought leadership? People will probably remember you more for how you conduct yourself on a project compared to the results you turn in.

How. Reflection on your own strengths, weaknesses, passions, leadership. Change focus from deliverables to benefits and value. Put yourself in stakeholder’s shoes. What experiences do they have when interacting with you? Consider the importance of ideas such as like networker, productivity, industry expertise.