Project Manager Course on Balance

Upcoming project management course ...

... "Project Management: Maintaining the Balance, will be held Tuesday and Thursday mornings from 8:30 to 11:30, Oct. 11 through Nov. 13. This course, great for IT project managers, helps organizations develop, continue, or complete large projects. " ...

Via iBerkshires: Project Management Course

Chief Innovation Officer: Get Trained

Attend training on the Chief Innovation Officer role. The Chief Innovation Officer course is targeted to push the frontiers of the field and brings into focus fostering innovation talent, creating portfolio techniques, and enabling business processes necessary to execute innovation projects in support of growth. ...

... "BMG's Chief Innovation Officer seminar is designed specifically for business leaders who are leading the charge for innovation inside their organizations. This 2-day interactive seminar features emerging strategies, tools and techniques from some of the foremost thinkers in innovation today.

Upcoming Seminar Date: 4/30/2007 2 days Denver, CO " ...

Chief Innovation Officer Seminar

Portfolio Management, Program Management, and Governance: A Rational Approach

There's an informative article by Michael Hanford on IBM's website about "Portfolio Management Governance." While it's aligned with IBM's Rational methodology, it provides useful information in general on the topic.

Many people confuse portfolio management, program management, and the relationship of governance to the both domains.

While there's no "right answer" per se, the generally accepted view is that portfolio management focuses on alignment with organizational strategy; setting priorities vs. resource and/or financial constraints; and insuring the right mix of initiatives to meet organizational goals. This is not unlike the management of a financial portfolio.

Program management on the other hand, deals more with execution of a group of related projects, insuring that the interrelationships are managed across them, and leveraging economies of scale (i.e. shared administration, management of benefits, etc.).

More importantly, portfolio management is ongoing and cyclical, while program management is temporary. Of course, some organizations refer to certain "channels" of work as programs, or even refer to mega-projects as programs, but the PMI Standard for Program Management considers these areas in the domain of functional/operational management or project management, respectively.

As for governance, it can work on multiple levels. There can be portfolio management governance, which makes decisions and sets policies at the portfolio level, or program management governance, which acts at the program level. Ideally the two work hand-in hand. For example, an executive council (and sub-councils if need be) can make decisions at the portfolio level (including authorization or termination of programs and projects), while a program oversight committee can govern a specific program, in alignment with the portfolio needs.

For more, here's the IBM article...

Establishing portfolio management governance: Key components

Is Project Management Relevant?

Over the years, I've had discussions with software developers who question the need for project management. I've heard everything from "The developers are the only ones who really know what's needed anyway!" to "All the project managers do is slow things down and add unnecessary bureaucracy!" to "Why can't the the developers just work with the customer to give them what they need and avoid the middleman?"

The fact is, given the right developer and a fairly isolated project, all of these are valid statements. But many projects are much more complex than that. They involve multiple stakeholders with conflicting needs, offshore resources, multiple vendors, complex interrelationships with other activities and departments, and more. They frequently involve managing all of this against budget and schedule constraints.

Leading, facilitating, and managing all of these elements is where a good project manager can help. An effective project manager removes barriers for a team rather than adding barriers. Any activities that may appear like "nuisance work" to technicians, such as reporting time or percent complete against milestones, are often necessary to meet the project's schedule or budget constraints.

A good project manager will work with developers to determine the appropriate project approach, depending on the constraints and the level of uncertainty involved. Perhaps an agile approach is warranted, with learnings applied incrementally. Perhaps piecemeal deliverables can be achieved for quick wins and earlier value. A good project manager will also prepare management reports, conduct presentations, and deal with vendor issues.

Most of all, a good project manager will communicate to all parties throughout the project. Although some developers do indeed have the expertise to do all this, it distracts from the work they need to do.

This is not just a nuance of the software industry. The same holds true in any industry where technical or subject matter experts question the need for project management. Project management is a completely different skill set, necessarily so. It's geared toward leading people to achieve objectives. An organization can of course put the project manager in a better position to be successful by providing adequate tools, general principles, and minimal bureaucracy.

The article below offers clear and simple evidence of the importance of project management. It begins with the results of a 1999 study that showed that the number one reason companies stopped working with Internet design firms was not about their lack of creativity or high costs---it was about their inability to effectively manage a project.

Here's the article...

MB Journal Article Archives

Empathy: Lessons from Iwo Jima

I just saw Clint Eastwood's magnificent film, Letters from Iwo Jima, this weekend. Of course, as usual I end up looking at everything through the lense of leadership and project management lessons, which drives my wife crazy.

The film offered numerous contrasting examples of good leadership and poor leadership. The differences weren't hard to spot. Besides strategic intuition, what separated the effective leaders from the rest of the pack (on both the Japanese and American sides) was an undeniable sense of empathy (much like the film's director, Clint Eastwood, did in making the film from the Japanese perspective).

Empathy, a key component of Daniel Goleman's Emotional Intelligence, is an undervalued trait in leadership. Equally important is the wisdom to know what to do with that empathy. In the film, the leaders who showed empathy and restraint were able to make the right decisions, even in the heat of battle. Their moral compass served them well. Ironically, it was empathy that led them to be able to predict the moves of the enemy as well.

Then there were the less effective leaders who blindly followed rules, thought only of themselves, were obsessed with power, and looked at people as objects to be used. Go see the movie. You'll see leadership styles worthy of emulation, and those to avoid. Ultimately, the film is about human decency and indecency.

Digital Lifestyle: Cavs Lead The Way

Cavaliers push limit of paperless, digital customer experience for ticketing in sports events. Of course, some resistance is inevitable. ...

... "While some major league baseball teams have introduced electronic ticketing, the Cavaliers have taken it a step further, providing a completely paperless transaction. " ...

Via Yahoo! News: E-ticketing

Requirements: Where Are You Headed?

There's a good article on Projects@Work about a project manager who won an iPod by submitting his story to a "Requirements Horror Story" contest.

I can relate to his horror as his boss touted their software's ability to "solve anything" to a client---software that, by the way, didn't exist yet.

His story makes the point that, unless there are agreed-upon requirements, there's no way to tell when the project is over.

I've sometimes had this debate with clients who are afraid to commit to requirements, preferring to keep things loose. While I'm all for "managing to the present understanding," and allowing for the ability to change course based on learnings, this should all be coordinated and agreed upon at every step of the way. There should at least be an initial set of requirements or objectives. It's hard to redirect your course if you have no course.

Here's the article. Maybe you have your own requirements horror story to share!

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

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.

Focus on Results, not Time: Best Buy Breaks New Ground

The other day, I posted a blog about the traffic anarchy experiment going on in Europe, where seven cities eliminated all traffic signs and the result was a reduction in accidents. My point was that if we focus on accountability and results, people will surprise us.

Well, Best Buy has taken that a step further. In the latest Business Week magazine, the feature story highlights Best Buy's daring new Results-Only Work Environment (ROWE) program. As part of the program, they have eliminated all work schedules in their participating areas and have practically eliminated meetings.

If someone wants to come in at 10:00am, fine. If they go to a movie in the afternoon, no problem. The key isn't how many hours they work, or even where they work (most workers are virtual most of the time). It's how well they achieve results.

Sound like chaos? Sound like people will just slack off? Well, once again the results say it all. For the divisions testing this method, voluntary turnover dropped dramatically (-90% for the Dot.Com division, -52% for the Logistics Division, and -75% for the Sourcing Division).

Sure, the turnover rate went down, but what about productivity? That too was greatly improved. The average rise in productivity for the participating divisions was +35% since the ROWE system was introduced in 2005.

Of course, what's important to making this work is to have the right metrics (i.e. customer retention, reduction in turnover, etc.). Many business mistakes happen because the wrong incentives are in place, leading workers to strive to meet a goal that sacrifices quality or is not in the best interest of the company as a whole.

The bottom line is that evidence is growing that we are better served by focusing on results over rules and policies wherever possible, something I've been saying for years. Now I'm glad to see some tangible evidence from those brave enough to try it.

Here's the Business Week article. Be sure to check the sidebar article about how to kill meetings!

Smashing The Clock

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.

Project Dashboard: Red-Light Root Cause

Project problems traced to leaders grades. ........ ;-) ...

... "His mother revealed that the man overseeing largest civilian IT project in the world failed his computer studies course while at Bristol University. " ...

Via This is London: Link

Yogi Berra on Project Management

There's a cute article in Computerworld called Yogi Berra, PMP. The article uses the baseball great's famous quips to make some compelling points about managing projects.

Of course, it didn't include one of my favorites as it applies to project management. When someone said to Yogi, "Hey Yogi, I think we're lost," he replied, "Yeah, but we're making great time!"

Unfortunately, this happens all the time in project management. Many methodologies focus on schedule, budget, and execution----and fall short when it comes to defining the problem and goals (and aligning them with the organization's needs). As a result, we end up getting to the wrong place fast.

Here are some other fun Yogi quotations, and here's the Computerworld article...

Yogi Berra, PMP

Lean IT Strategy: Virgin America

Virgin America needs a cost-effective, yet differentiated strategy, in the US market and its IT strategy must be based on a low-cost model. Its CIO plans to run an efficient data center, negotiate smart contracts, and leverage open-source platforms. ...

... "And their IT strategy will be, of course, lean and mean. " ...

Via CIO: Link ...

Company Info: A U.S. majority owned and controlled company, Virgin America intends to launch domestic U.S. scheduled airline service utilizing new Airbus A320 family aircraft beginning in 2006. The company has announced agreements to take firm deliveries of 34 A320 family aircraft including 19 purchased aircraft from Airbus and 15 leased aircraft from GE Capital Aviation Services. Virgin America's corporate headquarters is in the San Francisco Bay Area, and its principal base of operations is at the San Francisco International Airport. Virgin America's goal is to build an innovative, creative travel brand based on safe and efficient operations, low costs, outstanding guest service, and a unique level of engagement by its team. Its mission is to create an airline people love.

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

PMI Project of the Year: From Wasteland to Wildlife

I was recently in Seattle for a PMI leadership meeting as part of the core team for the Program and Portfolio Management Standards program. First, I was impressed by the beauty and cleanliness of the city, and the friendliness of the people. And of course I had to grab a coffee at the first Starbucks and see the guys at the famous Pike Place Fish Market throwing fish to each other. But I digress.

What really floored me was being at the PMI Awards presentation and seeing the short film on the project of the year---the Rocky Flats Closure project. This was a former nuclear weapons facility (and wasteland) that had to undergo an immense cleanup, including nuclear deactivation and material removal. Except the result wasn't a mere cleanup---the site was turned into a beautiful wildlife refuge, and will soon have a public space for hiking, biking, and horseback riding.

It demonstrates what can be achieved when you blend passionate leadership and sound project management. The project's website is below...

Welcome Rocky Flats Environmental Technology Site (Main)

Critical Chain fever chart example

This Critical Chain case study link includes some interesting tracking information. Anyone who has suffered as a result of a client’s internal politics and delays will sympathise with the tale of frustration. Assembling and temporarily disbanding the project team – sticking to the dictum ‘No multi-tasking’ – makes this case a more extreme example but very believable. CCPM is credited with being the project management approach that allowed this project to succeed. The fever chart is a graphic representation of how the Safety Buffer was used. A possible shock for people used to finishing a project in the green, the goal here was to finish in the yellow! The rationale of course is that staying in the green means that your estimates are too conservative!

Via Case Study: A Typical Critical Chain (CCPM) Implementation

SAP Users: ITIL Opportunity ...

Companies using SAP's ERP system have gaps in IT service management as defined by the ITIL standards. Referenced checklist is a source for self-assessment to identify strengths and weaknesses. ...

... "Of course, designing IT processes that conform to the ITIL can improve the quality of services only when it actually optimizes and reorganizes the IT service processes in a company. " ...

Via SAP INFO: Green Flag for ITIL?

Critical Chain again

This term's course includes the Critical Chain topic. So I'm looking around for more references and examples to illustrate the principles. This link is interesting for putting the emphasis on estimating, understanding and managing variation. Tony Rizzo, the author, goes on to examine the use of Critical Chain in a multi-project environment.
Another interesting observation is that the mainstream Project Management products do not support the approach.
The Project Management Soap Box: [17] The Critical Chain Model

PMI Announces Program Management Certification: Bring On the PgMP

PMI has finally announced the certification for program managers ---- the Program Management Professional or PgMP (the "sm" after the designation in the press release is for the service mark). It'll be available in early 2007.

The title is probably a good choice and has good synergy with the existing PMP designation. Of course, it's the same designation as the Program Management Plan (PgMP) from the Army Core of Engineers, so hopefully that won't cause confusion in those circles.

As I've mentioned before, the rigor of the PgMP requirements should give organizations a pretty good feeling about taking on program managers with this certification. It's based heavily on experience in the real world and feedback on results as opposed to pure knowledge.

Also, one needn't have a PMP certification to apply for PgMP certification. Here's the press release...

PMI to launch credential for program management practitioners

Talent Management: Readiness Survey Results ...

Interesting results of recent talent survey ...

Knowledge Infusion performed the 2010 Talent Readiness Survey in the early summer of 2006 to understand the talent gap to be left by retiring Baby Boomers. The study evaluates when people will leave the workforce, if there will be talent shortages that impact business outcomes, the steps organzations can take to find, develop, and retain the critical skills required for success. ...

The survey validates these findings:

Larger organizations are likely to impacted the most by the retiring workforce.

By 2010, a significant portion of the eligible workforce will retire.

To get ready: You must understand the impact on your organization. What percentage of your workforce could retire in four years? If succession planning at your company is focused more on the executive ranks, now is the time to apply succession modeling to your critical skills. Take a skills inventory. Understand the skills across the workforce demographics. Develop a plan to attract and retain the critical skills for your organization.

And, of course, digitizing your talent data enables your organization to provide visibility to this critical workforce information. Cornerstone OnDemand provides integrated on-demand solutions for talent management.

Via Cornerstone OnDemand : Managing Talent in the Face of Workforce Retirement ...

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

Einstein Project Management Tip #5: Imagination Counts

Our next project management tip from our Einstein series regards the need to challenge the status quo----to think out of the box. Consider this quote:

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

Of course, Einstein also famously said, "Imagination is more important than knowledge." To a project manager, who's typically focused on things like scheduling, monitoring, reporting, and driving the team to completion, this can be a particular challenge. But it's important nonetheless.

Imagination is required in many situations, including (but not limited to):

• Achieving success when the odds are against you
• Conceptualizing ways to achieve the objectives more effectively
• Brainstorming solution ideas and possible risks
• Overcoming barriers, whether political, technical, or physical
• Improving the cusotmer experience

For some practical advice on building the right team for innovation, see my blog series on Tom Kelley's The Ten Faces of Innovation.

More to come.

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

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.

Strange Project Risks: Mystery Woodpecker Halts $320 Million Project

Here's one that probably won't turn up on anyone's project risk template. The $320 Million Grand Prairie Irrigation Project, being led by the Army Corps of Engineers in Arkansas, has just been put to a halt by a federal judge because a rare, thought-to-be-extinct (and maybe still extinct) woodpecker was allegedly sighted two years ago.

The ivory-billed woodpecker was apparently spotted by a kayaker in 2004, which triggered a series of petitions and lawsuits by environmentalists to stop the project. The bird hasn't been seen since. Of course, I'm sure there are environmental issues beyond just the woodpecker, but the woodpecker seems to be the driver behind the decision.

According to the Houston Chronicle, about $80 Million has been spent so far, with a goal of delivering water to farmers by 2010 or 2011.

Here's the story...

Woodpecker Halts Ark. Irrigation Project - NEWS - US NATIONAL - Comcast.net

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 bar appropriately high.

But I can't help but feel that, in contrast, the PMP credential is losing steam. First, there are myriad organizations virtually guaranteeing an "instant-PMP" after a crash course and some tweaking of one's background experience (although PMI is now doing audits of work experience).

Second, a project manager must, in many cases, go beyond the PMP/tactical focus and possess the same traits and skills that PMI has designated as requirements of a program manager, especially in the case of an enterprise and/or global project, such as a business transformation effort. I realize PMI's role definitions are a way to differentiate and justify the new certification and I suppose one could organize their effort into a "program" to qualify for that certtification, but in these changing times (and with greater challenges for project managers), I think PMI needs to evaluate and revamp the PMP certification as well.

When I do presentations on principle-based leadership training, I have a slide where I present what I call "The PM Challenge." I present it as a boxing match. In one corner, we have a project manager, armed with MS/Project and the PMBOK, but lacking:

• Business Acumen
• Leadership Skills
• Conflict Management Skills
• Negotiation Skills
• Presentation Skills
• Communication Skills
• Strategic Intuition

In the other corner, we have the "challenger," represented by "the project," with the following characteristics:

• Global, virtual team
• Complex technology
• Complex change
• Multiple vendors
• Offshore resources
• Conflicting Stakeholders
• Scrutinizing Executives

Such a project manager, without the appropriate leadership and soft skills, doesn't stand a chance. Wouldn't a person with the skills PMI describes as a "program manager" be more apt to have success?

In the latest PM Network magazine from PMI, there are not one, but TWO articles that illustrate this point. One is titled "Project Management 2.0: Project Management is at a Crossroads," by Peter Fretty. The other is titled "No Limits," by Marcia Jedd, and talks about what project managers must do to crash through the glass ceiling and elevate it from the tactical trenches.

Perhaps a start would be to take a new view of project management beyond just "executing to a set of requirements to deliver on-time and on-budget." The current tactical focus might explain the consistent failure rates of projects. One problem is that PMI has traditionally "followed common good practices in the field," which of course is what a standard is supposed to do. The problem is that common practices have brought common results, which aren't all that good. Time for an upheaval. Perhaps they need a section, apart from the "standard" itself, for "new frontiers in project management," which could outline those who are breaking the mold with good results.

I'd be interested in others' thoughts on this topic. Who knows---It just might help drive requirements for the next version of the PMBOK and/or PMP credential.

Requirements Gathering Critical To Success

Well, I'm back from a wonderful vacation in the Bahamas only to return to torrential downpours in Philadelphia. But I digress.

A project that ends well must begin well. So says an insightful article in Computerworld on the importance of effective requirements analysis.

Some key points raised in the article:

• Ask. Then ask again (think Peter Senge's "five why's" where you ask why five times until you get to the root of the problem).
• Interview all levels of staff and management to get different perspectives
• Interview them via multiple vehicles to get different types of answers (i.e. surveys, one-on-one interviews, and facilitated workshops).
• Do user walkthroughs to uncover the real and/or unspoken needs (or as Toyota's slogan goes, "Go and see for yourself")

Of course, I'm also reminded of Henry Ford's statement, "If I asked my customers what they wanted, they would have said a faster horse."

Here's the article...

What Do Users Want?

IT Project Missing Ingredient: Professionalism?

UK computing leader sees genuine professionalism as key ingredient for transforming IT project success rates. This is a good thing, if interpreted as developing our talent in the industry. Is industry accreditation the answer? It should not be a substitute for creating leadership in achievement in an enterprise, where an environment of continuous improvement supports learning from lessons, improving processes, and expanding the knowledge of project management practitioners. ...

... "It would make my day if somebody brought me a failed IT project that had failed for novel reasons. Of course, nobody ever did, because his contention is that we understand why IT projects fail, and we keep making the same mistakes. " ...

Why IT must get more professional: Via ZDNet Asia ...