Driving Solution Adoption after Project Go-Live

Are there parallels between project delivery / benefits realization and the behavior of the market under bear conditions. Contrarians begin to notice when to make an investment. And, eventually the herd turns and the market moves. Can we learn from this phenomenon and translate into the project space? ...

... "Researchers who study nonconformity, fads, even game theory, agree that in any declining market, investors will inevitably begin to bet against the behavior of the herd. Many of these initial contrarians may be working from their own analyses ... " ...

Via New York Times: How to Turn a Herd

Adoption Risks with Innovation Projects

Whether you are implementing a fundamental new innovation or providing a new way to do things, cultural adoption is a risk you can't overlook. Considering your change management strategy? Do you promote methods that drive addiction or use Frankenstein to your advantage? Read on for some insights. ...

... "Great innovations have foundered over human stubbornness. ... Resistance to technology is an omnipresent risk for every innovator. " ...

Via New York Times: Risk

Project Advice for 2008

Advice for the new year includes building better business cases and planning for the organizational changes needed to operate new business processes enabled by technology implementations. ...

... "If your business case can't stand up to careful scrutiny and evaluation, then it's highly likely the project will experience significant downstream problems. " ...

Via ZDNet: Five Tips for IT success in 2008

Agile Scrum Concepts Discussed

Ken Schwaber, the original scrummaster, visits the Googleplex to discuss agile techniques. ...






The Agile Alliance

A Goose Learns to Lead: Meet Gregory

I just returned from a mind-altering three-day thought leadership summit in Connecticut, hosted by Judith Glaser, author of Creating We and The DNA of Leadership (both of which are landmark books for leading change and ensuring alignment in your organization or team).

At the summit, which we collectively titled The First International Creating We Summit, we engaged in deep conversation and shared the most groundbreaking tools for facilitating real change. Present were the leading thinkers from a variety of disciplines, including organizational development, neuroscience, psychology, and more. The mutual benefits and shared learnings were so great that we realized we need to keep working together on an ongoing basis.

Rest assured, more will come from this, so stay tuned. Meanwhile, we got to preview a new video from Judith Glaser, called The Leadership Secrets of Gregory Goose. Don't let the title, or the simplicity, fool you. This animated short packs a wallop in its short 6 1/2 minutes, and is bound to generate discussion among leadership teams who watch it. The purpose of the video is to help leaders understand how sharing power releases the leadership instincts in others.

Here's a brief snippet, along with information for ordering it (the package comes with a facilitators guide and power point presentation, so you can conduct your own workshop with the video). If you order it, tell them PMThink sent you.

The Leadership Secrets of Gregory Goose by Judith E. Glaser :: Benchmark Communications, Inc.

Engage Stakeholders for Project Success

Some tips on positioning a project for success, including video insights. ... Have you identified your user community? Will you need super-users in the community? How will you incorporate user ideas into solution design? Will you need their help in the testing phase? How else can you keep users engaged before the final cutover? Have you segmented the stakeholder population, looking for evangelists or early-adopters to provide the right buzz? As project manager, you may not have time to do all of this, but identify a role on your project team to take on these actions. They'll pay off. ...

... "ensuring that the right stakeholders have been identified, particularly in an IT project – the user community, and that there's a mechanism for them to be involved in the project design and monitoring the progress of the project as it proceeds. " ...

Via Canada ITWorld: Stakeholder collaboration

Change Management Situational

Get aligned, find a champion, and leverage the art of change management to your project situation. ...

... "In my experience, successful projects tend to revolve around a certain type of project manager or coordinator. Someone who really knows the organization, is respected, collects chits constantly, listens well, doesn't personalize disagreement, remains flexible, and generally wraps a friendly persona around a persistent pursuit of project objectives. " ...

Via CMS Watch: Change Management Challenges

HR and IT Collaborate For Successful Change Management

HR and IT have areas of synergy that contribute to successful projects. The workforce and key talent have a special role in embracing organizational change. ...

... "If successful, the plan will produce a community of people who understand the reasons behind the change, the impact on their roles, and their role in the success of the transition. " ...

Via SMBedge: HR and IT Collaborative Success

Project Failure Brings Great Lessons

Andrew Makar has an excellent article on Projects@Work outlining key lessons from a prior project failure. I even like his tag line stating that he is "focused on effectively translating project management theory into actual practice." Indeed, that's where the real lessons are to be found.

It looks like it's part of a series---at least a two-parter. This one has lessons about defining clear roles up front, keeping the same project manager throughout the project, maintaining a "living schedule," prioritizing elements in project scope shoulud tradeoffs be needed, and establishing a clear change control process.

I couldn't agree more. Read on...

http://www.projectsatwork.com/content/Articles/235962.cfm

Project Sabotage

If you wanted to sabotage a project even if leadership showed support for it, what would you do? Leadership support is necessary, but not sufficient. Look out for these signals. Have a strong change plan than purely compliance-driven, unless absolutely necessary. ...

... "Confuse meetings with plausible, but pointed, questions. Be too busy to do what's expected of you, e.g., fail to supply data or other resources. Or send a subordinate in your stead " ...

Management Support: Panacea?

IT Project EQ Change Project

For an IT project to have impact, it must affect change. For change to stick, leaders must provide support. Recent study looks at IT projects and the distance of senior leaders, such as CEOs. ...

... "We have to get good at how our organisation handles change - that's nothing to do with IT, but no IT project worth its salt doesn't affect change, said Green. " ...

Via ITPro: CEO IT Imperative

ITIL and Project Management: A Primer

For anyone managing IT projects, you may have come across ITIL (Information Technology Infrastructure Library). If not, you will. It's fast becoming the de facto standard for IT services. This article from CIO Magazine offers a good primer on ITIL.

Many organizations mistakenly look at project management and ITIL as two distinct paths. Forward-thinking companies integrate the two, with project management methodologies blending seamlessly with ITIL's best practices in change management, release management, configuration management, and other processes.

Here's the article...

The ABCs of the IT Infrastructure Library (ITIL) - ITIL - CIO

Management Truths: Can You Handle It?

Jack says you can't handle the truth. But if you're ready, I highly recommend Stephen Robbins' excellent book, The Truth About Managing People... And Nothing But the Truth.

Robbins has sold over 2 million copies, and I can see why. In plain, simple language, Robbins outlines 63 truths, supported by evidence, stories, and examples. Each truth is only a few pages, so you can open the book up at almost any page and find a gem. The whole book is under 200 pages in a small paperpack format.

The 63 common-sense truths span the areas of hiring, motivation, leadership, communication, team building, conflict management, job design, performance evaluation, coping with change, and managing behavior.

A few good lessons (paraphrased):

1) Productivity usually breeds satisfaction, rather than the other way around.

2) When interviewing, don't go on traits. Instead probe about past behaviors (i.e. "Tell me about a time when you ....")

3) Put people in jobs that match their personalities.

4) Out of all the traits people have, conscientiousness is the most frequent predictor of success.

5) Specific stretch goals produce higher output than generalized goals like "do your best."

6) Not everyone wants to participate in setting their goals. It depends on their nature, ability, time available, and other factors.

7) Judge behaviors, not people.

8) There's something to be said for "looking the part of the leader."

9) Expect the best and people will deliver. Expect the worst, and people won't dissapoint.

10) Experience isn't always a good indicator of success.

11) There's no ideal leadership style. Directive or supportive styles can work in different situations.

12) Teams often create negative synergy. Beware of loafers. Be sure to identify and measure individual efforts as well as team efforts.

13) Honor the work-life balance. Give flexibility and options.

14) Beware of the quick fix. What works for one company or problem doesn't always work for another.

For many more, and further explanations and examples, read the book!

Project Management Imperatives: Ten Keys to Success

Someone recently asked me what I felt the critical success factors were for any project (i.e. what were the top "must do's"). Although I can think of many more, here were what I felt were the top ten:

1) Get the roles right. (Insure accountability; use a RACI chart or Responsibility Matrix so roles are clearly defined. Insuring people understand their commitments up front will avoid problems later.)

2) Get the goals right. (Make sure all the key stakeholders agree on the goals. I've seen more projects go wrong for this reason than any other. Time spent here will pay dividends later.)

3) Get the current scope right. (I say "current scope," because change should be expected. Projects by default contain change because they are unique in nature. It's not whether you'll experience change, it's how you analyze the potential impacts and manage the approval of the change that counts. Agreed-upon and approved scope changes are perfectly acceptable, with one caveat: It's often wise to set a limit to the number of times scope can be changed for the current product release, and defer some changes to a subsequent release, else value gets delayed.).

4) Obtain commitment from the business, customers, and other stakeholders as to their part in the success of the project. (Many projects derail because the customer doesn't live up to their side of the bargain, doesn't understand their side of the bargain, or some other necessary constituent isn't cooperating for various reasons. Obtain the right commitment up front, starting with senior management.)

5) Determine the critical success factors and risks. (Critical success factors and risks go hand in hand. Many people ignore this or sweep it under the rug, and accept any related risks as a given. The critical success factors will identify related risks and help set expectations).

6) Set expectations. (This is frequently overlooked and is a key cause of failure. The sponsor, customers, and anyone impacted by the project must be given realistic expectations for what is needed from them, how long the project will take, how much it will cost, what the uncertainty factor is, what the available resources are, and anything else necessary to avoid surprises and/or an under-equipped effort.)

7) Beware of conflicting directives. (I call this the "Robocop Syndrome." In the film, Robocop, the titular robotic policeman goes on full tilt when he encounters directives that conflict with his primary directive. I see this happen often in organizations where a project sponsor demands something that is in conflict with other key stakeholders' wishes and/or top organizational directives. This could be covered under "goals" or "expectations," but it's so important that it warrants its own point. The project manager must head this off at the pass before the project goes down a rat hole it won't recover from.)

8) Plan Collaboratively. (The act of planning is not an isolated exercise. It's a collaborative exercise and should be done with the project core team and subject matter experts via some sort of facilitated brainstorming session---possibly with sticky labels on a wall.)

9) Beware of unilateral and granular "one-size-fits-all" solutions. (This is often ineffective, both as a project management methodology and a process implementation policy. Look at the big picture, and the potential variations. Keeping a framework high-level can allow for greatest flexibility and adaptability. Aim for principles over rules wherever possible. Use rules when safety is involved, regulatory requirements exist, or exact accuracy is needed---per Marcus Buckingham's guidelines from "First Break All the Rules.")

10) Don't let rank set you off course. (Often, a senior manager pulls rank and makes requests that are either detrimental, unwise, or in direct conflict with organizational goals. When this happens, see rules 6 and 7. It is the project manager's responsibility to set the right expectations, warn of potential risks, and head off potential conflicting directives at the pass.)

There it is. My list of "must do's." Project management isn't rocket science. In fact it's not a science at all. It's more of an art. Hopefully, the guidelines above can serve as a useful palette.

Influencing People: The Project Manager's Secret Weapon

I recently attended a presentation on self-awareness and influence by Dr. Charles Dwyer, Academic Director of the Aresty Institute’s Leading and Managing People program in the Wharton School. I was so impressed with the presentation that I bought his book, The Shifting Sources of Power and Influence.

This book was a real eye-opener, and a jewel for anyone in project management. In the book, Dwyer states three major challenges we all face:

• Dissonant Value Systems (i.e. people’s conflicting value systems, made even more visible by the advent of the media, internet, etc.)
• Diffused Power (i.e. power being spread around in a matrix fashion, with more and more decentralization and special interest groups, etc.)
• Limited Resources (We all face a limited set of resources, made even more challenging by our lack of a mindset geared towards accepting tradeoffs, or a good mechanism to guide operational priorities)

Sound like any projects you know?

Dwyer goes on to caution that public statements, such as vision, mission, organizational values, etc. may be useful for articulating the values of the leadership or giving people a sense of structure, but do not in themselves change anyone’s value systems. Many leaders assume they can use these statements to change people’s value systems to match organizational values, but this is a myth.

What is needed instead is the ability to influence others by getting them to change their behavior to match your values. To do this, have a clear picture of what you want the unit to look like; set specific, measurable objectives; and insure that people have a way of achieving those objectives.

According to Dwyer, some tried and true methods include asking people for help, offering or implying something in return, or influencing indirectly (i.e. working through someone else who’s in a better position to influence).

Dwyer points out five guidelines for influencing people (I’ve paraphrased them):

1. Insure they have adequate capability (Do they know what to do, have the competence and self-confidence to carry it out?)
2. Address their perception of “Potential Value Satisfaction” (WIIFM or “what’s in it for me”)
3. Address their perception of the probability of value satisfaction (i.e. Do they trust you? You must build trust through visible examples.)
4. Address their perception of cost (Do this by giving them alternatives or a sense of options, and helping them understand the costs and implications.)
5. Address their perception of risk (Try to assume or distribute some of the risk. Don’t ignore it.)

These are the five things everyone weighs in their mind when someone attempts to influence them. In essence, the five elements (four of which are perceptions) make up an equation for behavior. We can influence people’s behavior by addressing this equation (I’ve paraphrased for simplicity):

Behavior=Capability + (Perceived Value * Trust factor) – (Perceived cost and risk)

These are just some of the gems of wisdom in Dwyer's book. He offers reams of memorable examples, often with a humorous style. With 90% of a project manager's job being communication (including influence), I highly recommend Dwyer’s book for project managers, or anyone in a leadership position for that matter.

Critical Chain Insights

There's a good article on Projects@Work about Critical Chain Project Management, with some insights from the field.

Still, organizations are slow to adopt it. The biggest roadblock is getting management to change their mindset, especially when it regards avoidance of multi-tasking and not focusing on task completion dates.

It's not foolproof, and makes some generic assumptions (i.e. assuming everyone pads their estimates), but certainly there are some valid points of CCPM that should be considered. Even if an organization doesn't buy into all its philosophies, they shouldn't throw the baby out with the bathwater.

Here's the article...

http://www.projectsatwork.com/content/Articles/234283.cfm

Control vs. Accountability: Are We Our Own Worst Enemy?

In our never-ending struggle to gain more control over the chaos in our organizations, and with more and more focus on change management, who would think of going in the opposite direction and allowing more freedom?

Let's take a look at a story with some surprising results (sent courtesy of my old friend, Larry Beane).

Thanks to a project initiated by the European Union, seven sities and regions in Europe have completely done away with traffic signs. The originators of this idea must have been on to something. Contrary to the normal expectation that this would result in pandemonium, the accident rate went down!

Now arguably, this may or may not work in a congested city, but it got me thinking about the need for accountability. Perhaps the more rules we inflict, what we're really doing is relieving people of accountability---the paradox being that we need to give people freedom to make them fully accountable. Otherwise, we claim ownership of the problem instead of delegating it.

This is not unlike Toyota's policy of trusting their work teams to solve problems independently, and trusting that if their solutions are wrong, they'll work to correct it and learn from the experience. This is what a learning organization is all about.

This isn't to say we should just abandon all change management processes. On the contrary, providing people with effective processes can lead to successful outcomes. But for each rule we devise, we should consider an alternate approach of holding people accountable for outcomes, and insuring they have the capacity to succeed. Yes, provide processes, training, principles, guidelines, etc. But then focus on outcomes and accountability. And allow for learning-based corrections.

It's a radical thought, but a little anarchy may just bring the control that we need.

Here's the article about the successes of traffic anarchy...

Controlled Chaos: European Cities Do Away with Traffic Signs - International - SPIEGEL ONLINE - News

Extreme Project Management: Reality Rules

I just finished reading Doug DeCarlo's book, Extreme Project Management. I met Doug at a recent PMI event we both presented at. Not only is his keynote presentation a crowd pleaser (hint: he plays the drums to illustrate the pace of a typical project and uses Noah's Ark as a sample project from the "ultimate Sponsor"), but his book is chock full of practical, immediately usable ideas.

I was amazed at how much his philosophy mirrors my own, with a focus on simplicity, value, results, and the understanding that change is inevitable. A key point of Extreme Project Management is that reality rules. Plans are nice, but then results must drive further planning instead of assuming reality will yield to the plan.

As an example of simplicity, consider what he calls "The Four Business Questions":

1) Who needs what and why?
2) What will it take to get it?
3) Can we get what it takes?
4) Is it worth it?

As another example, check out his "Three Sentence Project Skinny":

1) Who will do what for whom?
2) This project will be considered completed when: ___
3) Why? This project supports the organizations objective to: ___

The book also offers handy checklists (such as what to ask the sponsor during the first and secend meetings, etc..), the 4 Accelerators, the 10 Shared Values, the 7 Win Conditions, and more.

Although the book is the size of the Encyclopedia Britannica, it's extremely readable and has diagrams that bring together all the concepts in the book. I highly recommend it to anyone looking for a book grounded in reality as opposed to academic theory. Above all, this will help project managers succeed where the rubber meets the road---communicating and dealing with stakeholders.

Amazon.com: eXtreme Project Management: Using Leadership, Principles, and Tools to Deliver Value in the Face of Volatility: Books: Douglas DeCarlo

Quality vs. Quantity: Is it Really a Choice?

There's an article in CIO magazine about how business leaders are beginning to choose quality over quantity (although the evidence seems to be to the contrary). The article refers to quantity as faster, more, cheaper, etc. But is it really a choice?

With adequate up-front research, phased deliverables, frequent communication, and good change management practices, we can achieve both. Phased deliverables provide earlier benefits (i.e. speed), fact-based learnings, less resistance, less rework (i.e. cheaper) and many other benefits. Change management practices insure that the rollout of any new feature or product won't break something (the level of change management needed must of course be appropriate to the type of product and industry).

And so what if it turns out through the early phases that requirements must change or more features are needed? As long as the change impact is managed and the change is agreed-upon, that's perfectly fine. These value-based course-corrections are another advantage of phased deliverables.

These precautions are the difference between speed and haste. As Patton said, "Haste is speed without planning." Indeed, we can achieve quantity and quality.

Here's the CIO article...

Getting Quality Over Quantity Better the First Time Around - Business Pulse - Leadership RC - CIO

Process Change Management: The Challenge ...

Chris Koch shares insights on the challenge associated with changing processes, such as a data center's adoption of ITIL practices. The carrot and stick approach is outdated. The new science of change must create the spark that engages the workforce in the change by making their jobs more interesting, creating an appealing environment, and strengthening team relationships. ...

... "The change is part of a larger effort to implement the IT Infrastructure Library (ITIL) process framework to improve overall productivity. " ...

Via CIO: The New Science of Change ...

Change Management Project: HP Values Transplant ...

HP values in need of transplantation. Anyone up for that change management project? ...

... "HP needs a values transplant. Hard as it is to believe, the company that once was the epitome of wise management in the IT business has become a corrupt, dysfunctional travesty of itself. " ...

Via Computerworld: HP: No Surprise

Einstein Project Management Tip #7: Focus on Strengths

Marcus Buckingham said it in all three of his books. Peter Drucker said it. Warren Bennis said it. Dennis Littky said it. And Albert Einstein said it.

Specifically, Einstein said:

"Once we accept our limits, we go beyond them."

I think all the great thinkers agree that it's better to focus on strengths (yours and the individuals on your team) than it is to endure the futility of trying to correct weaknesses.

If we accept our limits and those of the people on our team (after all, as Marcus Buckingham points out, people's nature doesn't change all that much), then paradoxically we can rise beyond those limits.

If so many experts agree, then why do organizations persist in trying to develop people's weak areas to make "perfectly rounded people" instead of building on their strengths? If we instead worked around people's weaknesses, either with complementary partners, more fitting assignments, or support systems, we'd see much more productivity. Perhaps Peter Drucker said it best: "Make weaknesses irrelevant."

Soldiers and Heroes: The Right Mix is Key

Derry Simmel, who runs a compelling blog site called About PMOs (and is on the board of PMI's PMO SIG), has an interesting post about heroes and soldiers.

Soldiers, Simmel says, color within the lines and can be expected to be reliable, dedicated, and even anal at times. Heroes break the rules and tend to go their own way---they're about getting it done and getting it done fast. Damn the torpedoes.

But, as Simmell points out, an organization needs both to thrive. True, a team of all heroes can be chaotic, but a team of all soldiers will probably not bring about dramatic change.

It's all about synergy, and putting the right people in the right roles. It's also about the fine balance between exactitude, speed and flexibility (ironically three of Napoleon's six winning principles).

Building a team that capitalizes on the complementary personalities and skills of heroes and soldiers is a good recipe for success.

Here's the blog post...

All about Project Management Offices: Soldiers

PMOs and Resource Management: A New Role?

There's another interesting article at Projects@Work on PMO design.

This one, written by Terry Doerscher of Planview, endorses taking what I'd call a "whole systems" approach to PMO design---i.e. looking at the PMO in the context of the overall "technology services organization."

This means expanding beyond just the project management realm---in particular, facilitating the planning and prioritization of activities across projects and other work that compete for the same resources. In effect, the PMO becomes a facilitator for managing the supply and demand of all IT work.

I'd add that, while this is a worthy role for the PMO, there is some heavy change leadership that needs to happen in order to make this successful. All too often, organizations overlook this and throw the fledgling PMO to the wolves.

As for project management practices, Doerscher suggests taking a more realistic, iterative approach to planning---something I couldn't agree more with.

Here's the article, well worth a read...

http://www.projectsatwork.com/content/Articles/232633.cfm

Einstein Project Management Tip #2: Think Flexible

In keeping with our Einstein theme, here's our next project management tip from the great thinker himself.

"As far as the laws of mathematics refer to reality, they are not certain, and as far as they are certain, they do not refer to reality."

While Albert Einstein was referring to the laws of mathematics, surely this applies equally to project plans. We lay out in fine detail what we think is the ultimate plan that supposedly reflects reality. We make what we think are valid assumptions. Then, the minute it is published, things change. Life has a habit of doing that, despite our best intentions.

But we still need to go through the act of planning if we are to think through the risks and have a good chance at success.

Therein lies the paradox. We need to plan, and then we need to constantly revise the plan to match reality. Then we need to plan again. It's a continuous iterative process of course-correction. Perhaps it's why Eisenhower said, "Plans are nothing. Planning is everything."

For most projects, the old adage,"Plan the work and work the plan" should be taken in a different context than its original intention. We need to plan the work, and then we need to "work the plan" (meaning "continuously adjust the plan so that it remains adaptable") , as opposed to merely working "to" the plan.

Stay tuned for more Einstein project management tips.

ITIL CMDB: Survey Insights ...

Evergreen shares insights on aligning data center projects with creation of a configuration management (CMDB) database, which is a core component of ITIL. Current state information is needed to jump-start the CMDB, but the data must be maintained through change management to sustain its value to the enterprise. ...

... "As companies are gathering this data, Evergreen suggests that they adopt a CMDB approach to 1) aid in the execution of the data center initiative itself and 2) ensure that this critical data is kept current and made available to the rest of the organization. Key benefits of capturing and maintaining this data in a CMDB include better capacity and resource planning, reducing risk associated with failed change (and a lack of configuration knowledge), and better IT operations in general due to more current, accurate, and useful data. As a core component of the IT Infrastructure Library (ITIL), a CMDB contains relevant information about IT Configuration Items (CI’s) as well as their dependencies on and relationships with each other. A CMDB can include data specific to IT hardware, software, applications, documentation, personnel, and business domains. " ...

Via Evergreen Sys: Evergreen Systems Suggests Organizations Utilize Data Center Initiatives to Drive CMDB Adoption ...

Talent and Project Management

I received the latest PM Network magazine from PMI the other day, and several things jumped out at me, especially following my last blog post on the winds of project management changing.

First, Neal Whitten had a great article about how a project analyst (what I've often called a "project control specialist") can be a valuable aid to a project manager by taking on the responsibilities of: project tools management, plan development, sub-plan collection, project support, supporting project tracking meetings, filling in for the project manager at times, and other areas that can free a project manager up to actually lead the project.

It got me thinking about the talents needed for the project manager role, the project analyst/specialist role, and any other roles needed on the project. But more than that, it got me thinking about talent management in general, and what it means to the project management industry.

Just look at these headlines, all from this month's issue:

• Attracting--and Keeping--top talent
• Executive Identity: Project managers should learn to think like executives
• A People Person: Succeeding in project management---and getting what you need from thise around you---requires a well-honed set of people skills
• Virtual Reality: Dispersed project teams are sparking shifts in management and leadership styles

Clearly, the talents needed to manage projects go way beyond schedule, budget, and cost control. Notice I said "talents" as opposed to skills or knowledge. As Marcus Buckingham points out in his excellent book, First Break All the Rules, there is a huge difference between skills, knowledge, and talent. The first two can be taught. The last one--talent--is innate, and cannot be taught.

This becomes clear when you apply Buckingham's definition of talent as "ANY recurring patterns of behavior that can be productively applied." Everyone has talent. It's just a matter of discovering it and matching them to the right role. The key point is that a person's nature cannot change that much, so it's important to select someone with the right talents (i.e. innate traits). Once that's done, you need to set clear expectations, motivate the person (through praise and recognition of their strengths), and ultimately develop the person (building on the strengths that already exist instead of fruitlessly trying to fix weaknesses).

So what does this mean to the project management field? Everything. It means we need to begin thinking about these innate talents when we hire and assign project managers, when we staff the project, and when we consider how to motivate the team. The talents needed for each role will be different. And, based on the nature of the project and the stakeholders involved, the talent required to manage each project may be different. There is no "one size fits all" when it comes to talent selection.

It's not that skills and knowledge aren't important, but these two items without the correct talents will not bring about success.

What I like about Buckingham's book is that it's based on facts---years of research with the Gallup organization. Anyone who selects and manages people should read this book. And when you do, think about the diverse talents needed for each person on your team, and for the project manager role for each individual project.

Project Management Winds Are Changing

There's an excellent article by Betsy Morris in the current issue of Fortune Magazine about how the Jack Welch way of winning is---dare we say---a thing of the past.

How is this relevant to the project management field? Well, for one, it means recognizing the winds of change in the industry, and how projects are selected, promoted, and managed. Above all, this impacts program and portfolio management. Particularly, note four trends in management thinking:

Innovation:

Let's take Welch's old rule of being number 1 or 2 in your market (or else fixing, selling, or closing the business). The new rule is to find a niche and create something new. The article uses CocaCola as an example of a company that was basking in their glory as number 1, but eventually realized (although it took a while) that energy drinks and bottled water were about to pass them. As the article points out, energy drinks "are now expected to outearn every other category of soft drink within three years." Parhaps marketing guru Harry Beckwith said it best in Selling the Invisible when he said that it's fine to do something 10% better until someone else comes along and does it 110% different.

Customer-Centric Management:

Welch started a whole movement of focus on the shareholder, which led many organizations to ignore the future amid pressure to appease shareholders and "make the numbers." Now, organizations realize that the customer is king. The article references several companies that have made this realization, and the trend is heading in that direction. After all, statistics show that even a minor improvement in customer retention leads to a major increase in profitability. The days of short-term thinking may be finally coming to an end.

Reinvention vs. Incremental Change:

Since it seemed Jack Welch could do no wrong, everyone imitated whatever Jack did---and Six Sigma was no exception. The problem is that, according to the article, of the 58 large companies that announced Six Sigma programs, 91% have trailed the S&P 500 since. As the article points out, that's mostly because Six Sigma is intended to "fix an existing process," whereas innovative companies that developed new and unique products (or reinvented their business) took the lead.

Stop Ranking Your Players; Inspire Passion:

Once of Welch's most controversial systems was to constantly rank his employees and regularly weed out the "C" players. But companies have had difficulty getting productivity and innovation out of "increasingly disenfranchised employees." In the article, Christopher Bartlett of Harvard Business School put it best:

"People don't come to work to be No. 1 or No. 2 or to get a 20% net return on assets. They want a sense of purpose. They come to work to get meaning from their lives."

Side editorial: For the "enlightened" approach of finding the hidden strength in everyone (something Peter Drucker always suggested), read Marcus Buckingham's Now Discover Your Strengths (or any of his books for that matter). Or read Dennis Littky's The Big Picture: Education is Everyone's Business. I assure you, you'll never be the same.

Meanwhile, I highly recommend the article (the link is below) for those looking for the latest trends in management thinking, and who want to remain one step ahead.

From a project management perspective, the handwriting is clearly on the wall. The traditional "execute to a set of deliverables" approach won't cut it. Today's project manager needs to be thinking about things like innovation, customer focus, business transformation, business acumen, change leadership, and team passion. Those focused on merely schedule, budget, and scope will soon be dinosaurs.

Fortune: The new rules - Jul. 11, 2006

Data Center Change Automation: ITIL Support ...

ITIL support for data center management by BMC integrates change with availability and capacity. ...

... "BMC is the only vendor that delivers complete ITIL-integrated workflows for changes associated with server resource provisioning, allowing data centers to link their availability and capacity management processes with change management for more controlled, effective, and efficient use of data center resources. In addition, BMC's Data Center Optimization solutions deliver a comprehensive set of ITIL-based extensions for virtualization management and optimization. " ...

Via BMC Software: BMC Software Racks Up Another Industry First: Full Automation of Data Center Change Management ...

Is the Role of the Project Manager in Jeopardy? - An Editorial

A few weeks ago, I posted a blog about the new Program Management credential from PMI. In it, I referenced PMI's definition of a program manager vs. project manager in their FAQ page.

A project manager, according to PMI, has the following responsibilities (I've put some of the key points that jumped out at me in bold):

• Perform their duties under general supervision and are responsible for all aspects of the project for the life of the project
• Lead and direct cross-functional teams to deliver projects within the constraints of schedule, budget and resources
• Demonstrate sufficient knowledge and experience to appropriately apply a methodology to projects that have reasonably well-defined project requirements and deliverables.

A program manager, according to PMI, has the following responsibilities (again, I've bolded the key points):

Under minimal supervision, program managers are responsible and accountable for the coordinated management of multiple related projects directed toward strategic business and other organizational objectives. These programs contain complex activities that may span functions, organizations, geographic regions, and cultures. Program managers build credibility, establish rapport, and maintain communication with stakeholders at multiple levels, including those external to the organization.

Clearly, a program manager must be closely tied to the strategic goals and benefits, monitor the program accordingly, and have a strong connection to senior management. And I also feel that the new credential seems on the surface to set the