Project Forecasting: More Lessons from Driving

A while ago, I entered a post about the importance of staying tuned in, drawing an analogy to driving. Well, another driving analogy had occured to me, this time about the need to focus on remaining time.

Let's put it this way. If you're driving from Philadelphia to New York City and you're at the entrance to the New Jersey Turnpike, what percent complete are you on your trip?

Some of you may guess certain percentages based on distance, but that's as foolish as basing project percent complete on the percent of budget or time that's been spent, without regard for work accomplished.

The quick answer is: Who cares what percent complete we are? What we really should be concerned with is how much time is left, assuming we care about what time we arrive to begin with.

But let's say that we DO care (i.e. schedule is a priority for us, as opposed to some other success factor). How can we measure whether we'll be there on time?

Simply using a percent complete tells us nothing. It's too subjective. What we need to know how much time is remaining. And that will depend on how fast you're going, how many miles are left, what barriers may arise (i.e. road closings, flat tires, etc.), how many stops you make, and a number of other variables. It's no different for projects.

For project schedule control, capturing percent complete is too theoretical, so that's not of much use to us. And capturing time spent tells us very little, except perhaps how long it took us to do prior work, which may not be an accurate indicator of future work. Besides, we can probably determine future work estimates more accurately through expert opinion and/or statistical sampling (combined with good planning).

Of course, there's no harm in entering time spent as long as people are disciplined to always include time remaining. Then a percent-complete can be calculated based on that. But the percent-complete itself is not a leading indicator, so is still of questionable value.

If we focus instead on time remaining at the task level, and combine that with barrier removal, risk planning, and regular reforecasts, we'd have much better control over whether we "arrive on time."

We can improve our ability to estimate in the future by capturing lessons learned, doing spot checks, and using the information to create project schedule templates and checklists, so future projects can avoid running over the same potholes.

Some may say, "Oh, we still need the percent-complete for Earned Value calculations."

Do we really? By putting a dollar amount to the time remaining, we can solve the same problem in a simpler fashion, answering the question: How much is it going to cost us to complete this project and what's our estimated time to arrival?

Just some food for thought. See my followup post on Project Forecasting and Uncertainty as well.

All About OPM3

PMI's Organization Project Management Maturity Model (OPM3) is not without controversy, and things are heating up more than ever. Some tout it's ability to help organizations navigate a growth path and others claim it's too focused on academia and doesn't hit on real world issues facing project managers.

Here are a few recent articles that show the good and the bad ---- all you need to know to decide if OPM3 is for you.

First, this month, AllPM is highlighting articles on OPM3, including the following:

The Essence of OPM3

The Business Value of Maturity Assessment

OPM3 and your 'C' Level

Comparing CMMI and OPM3

For another perspective, there's a very insightful critique of OPM3 on Projects@Work:

Assessing OPM3

Of course, we need to keep in mind that it's the first iteration, and will evolve over time. I do know that there are major improvements in store for the next release. It'll be interesting to weigh in after the product matures. Meanwhile, it's a tool, and, like any other, can easily be misapplied or overused.

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.

Traditional vs. Agile Project Management: All You Need to Know

Here's the best article series I've seen to date comparing traditional "plan-driven" PMBOK practices to Agile "value-driven" approaches. It's a four-part series by Michele Sliger on StickyMinds.com.

Enjoy...

Column info : Relating PMBOK Practices to Agile Practices - Part 1 of 4

Managing the Grey Areas: Lessons from the Leadership Quadrant Seminar

On November 15th and 16th, I conducted a seminar with productivity consultant Jerome Jewell called The Leadership Quadrant: 4 Ps for Organizational Excellence. The 4 Ps are Principles, People, Productivity, and Process. It was held at the National Constitution Center in Philadelphia, and we incorporated the museum’s rousing multi-media show, Freedom Rising, into the seminar.

The seminar participants came from the healthcare, criminal intelligence, and manufacturing sectors, which led to some fascinating discussion and dynamics. With any seminar, the value to all in attendance is magnified by the contributions of the participants, and this was no exception.

In the seminar, which included sections on principles, emotional intelligence, systemic thinking, talent management, innovation, project management, and more, the collective group highlighted a number of “grey areas” that a manager must frequently weigh when making decisions.

Some questions arose, such as:

"What if someone no longer likes a role they excel at and prefers a role they're poor at?"

"Do people always need to see the big picture?"

"Should one person be expected to serve the role of a manager, leader, and administrator? A strategist and tactician? A generalist?"

"How do you strike a balance between effective time management and remaining available to your staff?"

"Are recurring meetings effective or are they time wasters?"

In line with these questions, below are some of the factors that managers must consider:

• People’s individual needs vs. organizational goals
• Big picture inclusiveness vs. security (or the desire to give people narrow focus)
• Using generalists vs. specialists (and where the specialty should focus – on a functional area or on a particular skill)
• Effective time management vs. flexibility and being available to your staff’s needs
• Recurring meetings vs. consideration for people’s time
• Informing vs. influencing (for deciding whether to email or meet; even then, the decision is not always straightforward)
• Innovation vs. execution (knowing when to move from ideation to “getting things done”)
• Systemic (whole view) thinking vs. systematic thinking (routine, repeatable process)
• Vigilance vs. delegation (how much is safe to delegate, and to whom?)
• Firm principles vs. ethical dilemmas (should a firm principle ever be bypassed?)

In all of these cases, the group determined that the answer isn’t always black and white, and that each situation requires weighing these items. The trick is to observe, orient, decide and act quickly (referencing Colonel John Boyd’s OODA principle).

On the item of firm principles vs. ethical dilemmas, the group applied lessons from various cases throughout history where the US Constitution was challenged. It was obvious that there was no “one size fits all” answer.

With more recent events, consider OJ Simpson’s book. If you manage a bookstore with a principle of defending freedom of speech, do you carry O.J. Simpson’s new book, even though it is "ethically challenged," to say the least? Most large-chain bookstores creatively tried to satisfy both sides of the equation by donating all of the proceeds to the victims’ families. Of course, in the end, the book was canceled, but for a while, this was a real challenge to bookstores.

All of this reaffirms that management is abstract, not concrete. Managers cannot have all the answers; but they can and must insure that the right questions are considered, and they must have the courage to make decisions.

IT Project Dashboard

Anecdote on IT project performance with mention of top 5 root causes. Chevron referenced for its management practices that focus attention on the highest value projects in its portfolio. ...

... "According to Accenture, the average IT project exceeds its projected cost and schedule by 56 percent and 84 percent, respectively. " ...

Via ITBusiness Edge: Link

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

Strategic Portfolio: High Value Differentiated ...

Chevron has created a governance framework for actively managing its high-value enterprise-level projects, differentiating from its volume of small projects. The high-value portfolio is also where most of the investment is aligned. ...

... "it's a strategic framework for the company's biggest and most important IT projects. It's intended to ensure that the projects with the biggest benefit to the company as a whole get the right funding at the right time, and that they get special management attention. " ...

Via Computerworld: Chevron: Where Size Is Opportunity

Technology Evolution: Call to Green Action ...

As computing density increases, power consumption is spiraling out of control. It is time for the Information Technology industry to do its part in energy conservation and management. ...

... "Chief information officers need to wake up to the issues of spiralling energy consumption and environmental legislation, and develop greener approaches to IT, according to Gartner. " ...

Via ITNews Australia: Gartner urges IT to go green ...

A green strategy can include server virtualization which increases asset utilization and lowers the energy footprint of the datacenter ...

IBM VIRTUALIZATION SERVES UP COOLER SYSTEMS FOR US OPEN TENNIS EVENT: "Virtualization technology, which IBM has been providing to clients since before Arthur Ashe won his first US Open title in 1968, allows many computing resources to act as one and, more commonly, one computer, storage device or server to divide its own workload and act as many different resources. By reducing the number of computers and servers in use, virtualization helps minimize the often strenuous and expensive power and cooling demands of datacenters and eliminate unnecessary maintenance expenses. "

IT Governance: Firing on All Cylinders ...

An IT Governance Practice Director offers some good insights on successful IT governance, which requires progressing your maturity across multiple dimensions of management: portfolio, project, resource ... leading to the end game of transforming IT into a powerhouse of value creation. ...

... "Successful IT Governance requires effective portfolio, project, process, financial, resource, risk, and communication management. It requires the IT organization to switch its mentality from that of a cost center - We're just here to keep the lights on - to that of a profit center ... " ...

Via ITworld: Getting Started With IT Governance

IT Project Management Book For the Ages

For those managing IT projects, an invaluable resource is Jolyon Hallows' comprehensive book, Information Systems Project Management. Be sure to get the 2nd edition (link is below). It's a bit expensive, but Amazon has it used as well for less money.

Even though I've been managing projects for years, I always like to check out various books to gain new perspectives. This one is exceptional. It offers practical advice with"what if" situations covering most political quandaries, handy checklists (there's a great one on scope considerations), and concise "real word" tips on using various methodologies.

If you're an IT project manager and only buy one book this year, this is it. Of course, if you buy two books, you can check mine out as well. :-)

Amazon.com: Information Systems Project Management With Infotrac: How To Deliver Function And Value In Information Technology Projects: Books: Jolyon Hallows

Project Risk Management

Oil production company, Venture Production PLC, uses risk management software to model project scenarios to select optimum schedule while balancing risks, costs, and time performance. This seems a worthwhile approach, when large investment is at stake and time to value is critical. ...

... "Using Pertmaster, Venture's project management team was able to add a risk dimension to plans built in its Primavera P3 scheduling solution. Venture then analysed the schedule-risk of multiple scenario options to look at the most probable outcomes of each, in terms of both timescales and costs. This enabled the best options to be highlighted when considered from both likelihood of risk occurrence and degree of impact and enabled management to take well-informed decisions. " ...

Pertmaster Helps Bring Venture's New Oil Field On Stream ...

Venture Operated Goosander Field On Stream: "Goosander has been developed as a sub-sea tieback to the Venture operated Kittiwake platform utilising two subsea flowline bundles totalling 12 kilometres in length. The bundles were manufactured and installed by Subsea7 from their construction site in Wick and have been designed and engineered to accommodate future production and water injection wells and the potential for re-use on future subsea tie-backs. "

PM Lessons from Einstein: Summary

Here's a summary our project management lessons from Einstein (with links to the original posts) ...

1) Goals Rule ("Confusion of goals and perfection of means seems, in my opinion, to characterize our age.")

2) Think Flexible ("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.")

3) Silence is Golden ("If A=Success, then the formula is A=X+Y+Z. X is work. Y is play. Z is keeping your mouth shut.")

4) Think Value ("Strive not to be a success, but rather to be of value.")

5) Imagination Counts ("To raise new questions, new possibilities, to regard old problems from a new angle, requires creative imagination and marks real advances in science.")

6) People Matter ("Concern for man and his fate must always form the chief interest of all technical endeavors. Never forget this in the midst of your diagrams and equations.")

7) Focus on Strengths ("Once we accept our limits, we go beyond them.")

8) Think Simple ("Any fool can make things bigger, more complex, and more violent. It takes a touch of genius---and a lot of courage---to move in the opposite direction." BUT... ""Everything should be made as simple as possible, but not simpler.")

Einstein Project Management Tip #4: Think Value

And so we continue our series on project management tips from Albert Einstein. Here's another...

"Strive not to be a success, but rather to be of value."

This sums up perfectly the problem with most projects today. They focus on "success" without fully defining what success means. Project managers and PMOs track schedule and budget metrics. Then, at the end of the project, some capture customer satisfaction, almost as an afterthought.

What really needs to happen is to insure value to the customer, and this usually goes way beyond being on time and on budget. We spoke about the need for clear goals. Surely that's part of it. We also need to deliver in small, frequent iterations to provide the quickest value and get more immediate customer feedback.

Customer satisfaction should be measured and tagged as an index throughout the life of a project, just as Earned Value uses indices to track cost and schedule performance. This allows course correction to be made in areas such as goal clarification, communication, and other areas needed to provide good value.

And when the product has been delivered, be sure that the customer can maximize the benefits of the product through proper training, tips & techniques, next steps, or any other items that will help them get the value expected.

These are the very items I've attempted to address with my Service-Oriented Project Management (SOPM) framework, with its four phases of Understand, Prepare, Iterate, and Transform (UP-IT).

More Einstein tips coming soon...

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 ...

PPM / EPM Software Market: HP Acquires Mercury ...

HP acquires Mercury and creates a $2B software line of business. The software LOB seems like a complementary fit - infrastructure software and application management / EPM governance software. It was inevitable that Mercury would be acquired, given the consolidating EPM market. HP paid a sizable premium - a nice bonus for Mercury shareholders given delisting. Mercury customers should be delighted - some stability - and likely continuing investment in the application suite. ...

... "HP announced that it has signed a definitive agreement to purchase Mercury Interactive Corp., a leading IT management software and services company, through a cash tender offer for $52.00 per share, or an enterprise value of approximately $4.5 billion, which is net of existing cash and debt. " ...

PPM / EPM Software Market: HP Acquires Mercury: Via HP: HP To Acquire Mercury Interactive Corp.

Elusive IT Project Value: Book Tells How To Achieve It

I've just finished reading an excellent book on achieving value from IT projects, The Information Paradox: Realizing the Business Benefits of Information Technology, by John Thorp and the Fujitsu Consulting's Center for Strategic Leadership.

Thorp and company claim that today's IT projects are evolving more and more from simple automation efforts to complex "information" initiatives, and even further---to complete business transformation initiatives. This calls for a different approach and requires IT and Business collaboration.

As the book points out, the classic "let's buy a product and assume it comes with automatic benefits" approach doesn't work in today's more complex arena (and in fact it probably never did). In a complex business transformation initiative, trying to assume that an IT project in isolation will deliver value is wishful thinking.

The book also points out the four critical dimensions of complexity, which it says are blind spots in traditional thinking:

1) Linkage - to other related initiatives and to business strategy
2) Reach - those areas of organizational structure or supply chain processes that may be impacted by the change, or that need revisiting in order to bring about the benefits
3) People- those affected by the change and/or that need to be engaged (i.e. proactive change leadership and stakeholder analysis)
4) Time - the time it takes to manage the overall initiative, including the above dimensions, to fully realize the benefits (most companies grossly underestimate this)

Unfortunately, many IT projects just focus on on-time and on-budget delivery (resulting in a situation that the book describes as, "the operation was successful but the patient died"). Thorp and company refer to this as "investment myopia."

Instead, a committment to business value, ongoing process improvements, frequent iterations of delivery, and better project selection techniques are key. Most of all, we need to be aware of the blind spots mentioned above.

The book goes on to describe how a system of program management, portfolio management, and governance, with a focus on benefits realization, can bring about results. It also cautions about the dangers of treating selections as a one-time annual event, making selections in isolation (instead of in the context of investment programs), and not looking at all aspects of value (i.e. going beyond simple financial measures).

I highly recommend the book for those struggling with determining the value of IT, or trying to bring about collaborative change in their organizations. If you look at any major successful transformation, it was brought about by a marriage of technology, business process, and organizational change, and with full backing from senior management. This book can go a long way toward helping make this happen.

Earned Value Wikipedia: Your Chance to Contribute

Our friend Garry Booker of Project Frontier has revised the Wikipedia entry for Earned Value Management and is looking for feedback.

Feel free to check it out and update as needed. Also, here's Garry's introductory statements in the topic's discussion page.

His revisions have added some clarity, plus information on making EVM scalable to various size projects. There are some good diagrams and links as well.

Here's the link...

Earned value management - Wikipedia, the free encyclopedia

Change Management: IT Leads Insurgency ...

Robert Reich challenges IT leaders to embrace change and lead the insurgency brought about from the mega-trends confronting us. He highlights the importance of adding value and ignoring past models for success. ...

... "Organizations that will thrive in the global economy will be driven not by the short-term expectations of Wall Street, Reich suggested, but by his so-called change insurgents. These educator-executives can persuade managers to develop strategies that comprehend the structural economic change brought about by globalization, technology and the graying of the baby boomers. " ...

Via Search Oracle: Robert Reich tells CIOs: Rise up and adapt to global change ...

Earned Value EVM Adoption Growing?

Earned value management is seeing adoption outside of traditional user base, through mandates and associated success stories. ...

... "So EVM tells you — by planning and setting the milestones — whether you got the value for what you're paying for. I think people are starting to understand that. " ...

Earned Value EVM Adoption Growing?: Via FCW: Making EVM matter ...

PMO Success Story: A.G. Edwards Case Study

There's an excellent article in CIO Magazine this month showing how A.G. Edwards reinvented its PMO to bring their projects to an 88% success rate (from about 50% originally).

Some key lessons:

• They created a 25-step project management high-level framework of just the high level activities common to all projects. They didn't inflict a detailed application development methodology and left the "how" flexible, as long as the "what" was satisfied. At a more detailed level, they used Primavera for project tracking and dashboard metrics.
  
• They provided leadership training to boost the confidence of their PMs
  
• They moved the project managers from the PMO to the functional areas to encourage collaboration and better align the PMs with the business.
  
• They offered project planning services to assist the distributed project managers with using the new framework effectively (allowing them to use the planning tool of their choice, be it Excel, MS/Word, or a whiteboard). The 25 framework touchpoints, however, are common to all projects for cross-project comparison purposes (I assume enabled in Primavera).
  
• They redefined "success" as "projects that deliver business value." This gives customer satisfaction and business value even greater priority than being on-time and on-budget (note: they still improved their schedule and budget statistics anyway).
  
  This is the essence of the new model and bears repeating. The customer defines success. Under this model, it's quite possible to have a project that is late and over-budget and seen as a raving sucess.
  
• They tirelessly met with stakeholders in individual and group settings to offer the benefits and ask for their support. They used a subtle soft-sell approach with the "bad actors."
  
• They first involved the PMs receptive to new ideas as part of a pilot and them used them to "spread the gospel"
  
• They measured success rates and publicized them in quarterly reports to senior management.

These are all powerful and valid ways to make a PMO successful, and are philosophically aligned with the Service Oriented-Project Management (SOPM) model I've been developing. In this case, these changes collectively served to boost IT's credibility at A.G Edwards significantly.

Here's the full article. Don't miss the sidebar "8 Steps for Improving Project Management."

When Failure Is Not an Option - Editorial - CIO

Project Management Holy Grail; Keep Searching

With all the hoopla over the DaVinci Code, I figured I'd share this insightful article from Max Wideman on what many have considered the "Holy Grail" of project management---the ever elusive set of "best practices."

Wideman rightfully argues that any list of best practices is likely tainted, because who'd want to share anything so groundbreaking that it gives them a competitive edge---and if it was so groundbreaking, it would most likely get lost in the survey process that looks for frequently used practices.

So, instead of best practices, we end up with "common practices," which in many cases are extremely flawed.

Better to break new ground and look for unique approaches that fit what you are trying to accomplish, or look for the best examples of what some other organizations are doing. But beware of surveys that claim they show "best practices."

When it comes to project management, you'll just need to keep looking for the Holy Grail. Better yet, try to create one, as I'm attempting to do with my new Service-Oriented Project Management (SOPM)™ model, and others are doing, such as Garry Booker with his Streamlined Earned Value model and his other creations. But you won't see any of these on any "best practice" lists.

Here's the full article...

Max's Musings - The Fallacious Argument of Best Practice - Or the Holy Grail of Project Management

SOPM; A New Project Management Methodology

Service Oriented Project Management (SOPM) is taking shape as a methodology that fills the gaps in traditional project management, namely a RELENTLESS customer focus and the all-important analysis and benefits evaluation after the project has "completed."

As I fine tune the model, I'll post the iterations here, as a methodology in progress.

The four high-level steps in SOPM are as follows:

1) UNDERSTAND ... Develop an understanding of the problem being addressed, the goals, constraints, the internal environment, the external market, benchmarks, the people and subject matter involved, potential solutions, risks, benefits/justification, and any other knowledge necessary for success. Most of all, understand the customer.

2) ENABLE ... After helping the customer obtain approvals, prepare the project organization (resources, roles & responsibilities), operating principles, the infrastructure and tools needed to run the project, organizational alignment, preliminary training needed, communication, and anything else needed for a smooth road ahead.

3) ITERATE... Plan, design, build, test and pilot the solution before attempting a full scale implementation. Implement in phases to achieve quick wins, earlier benefits, and greater customer satisfaction. Consider iterative prototypes during the design phase. Don't forget additional training needed.

4) EVALUATE... After each project phase and at the end of the project, evaluate and document lessons learned, customer satisfaction, and benefits achieved (vs expected). This includes evaluating how the customer can achieve maximum results with the product of the project, and laying the groundwork for their continued success.

By using an UNDERSTAND, ENABLE, ITERATE, and EVALUATE process, with COMMUNICATE as an overarching activity that extends across all four steps, we adopt a much more holistic and customer-centered approach to project management.

A few key points... Customer satisfaction should be measured at milestones throughout the project, not just at the end. It's as important as monitoring cost and schedule (i.e. Earned Value performance).

Imagine seeing an S-Curve showing Planned Value, Earned Value, Actual Cost, and Customer Satisfaction. Maybe your project is on schedule and on budget, but the customer isn't satisfied with the results (or with the project communication, or a whole host of other issues).

A narrow focus on cost and schedule takes too much of an inward view. Besides, measuring customer satisfaction throughout a project allows for corrective action instead of managing in the rear view mirror.

More to come.

NOTE: I have since revised this model. See my updated entry.

Service Oriented Project Management (SOPM); Bridging Three Worlds

With all this talk about Business Process Reengineering (BPR), and the latest industry focus on innovation, I've been piecing together a model that brings together the best of BPR, Innovation, and Project Management (and even borrows elements of ITIL). I call it Service Oriented Project Management or SOPM. I believe the term has been used, but not in this context, and not as a formal model. I think it's important enough that it needs to be formalized.

There are some that view these three disciplines as separate, or even mutually-exclusive, but they're not. In fact, to be successful, these disciplines need each other. It should go without saying that BPR needs innovation in order to break new ground (resulting in dramatic and radical change, as opposed to incremental change). And project management skills are needed to keep a team on track and manage risk.

Certainly, there are situations where incremental change is quite appropriate, and, for these cases, process "improvement" disciplines such as Six Sigma and TQM are fine. But especially when radical change is needed, we need a superstructure of good project management to lead all phases of a BPR initiative, from the as-is state exploration, through the to-be state development and validation, and to the actual implementation of the initiative.

Likewise, project management in general needs the strong customer focus that BPR brings (usually sorely lacking in most projects). Almost any project can benefit from a BPR-type approach of getting to the root of the customer's problem first-hand, and bringing about dramatic results through innovative thinking. This also takes project management beyond the realm of simple "execution and control".

Using a BPR lifecycle, innovative thinking, and an overall project management approach, we get a holistic methodology that uses the best of each. And, if this is driven by overarching principles from all three disciplines, we can boost our chances of success exponentially.

And finally, there's the customer. EVERYTHING in all of these disciplines must have a relentless focus on the customer. With any initiative, the glue that holds all of this together is a service owner--- someone who understands the customer's needs (and their business) and owns the initiative from cradle to grave (just like an ideal order fulfillment process should be, according to Michael Hammer, the inventor of BPR). Whether or not this should be the project manager is a whole subject in itself, but it should be someone.

If the project manager does assume this role, then they had better have a strong customer and business focus, and be relieved of any project administration duties that aren't adding value to the customer (which can be assigned to a project accountant). In many companies, the project managers may not have the right skills for this role, but that's not to say that shouldn't change.

More to come, as I flesh out and develop the model. Meanwhile, I'm open to your thoughts on this.