Certifiably Green

As IT sustainability objectives become more prevalent, the British Computer Society creates a certificate in Green IT to prepare IT professionals for development of a green IT strategy. ...

... "By the end of the three day course, candidates will have a fundamental understanding of the importance of IT when trying to achieve an organisation's green objective, an ability to identify their own green IT requirements and how to address them. " ...

Via British Computer Society: Green IT Qualification

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

Management vs. Leadership - Revisited

From Bold Vision Business comes a great article on management vs. leadership.

I've written several times here on that topic, where I often say "there's no difference if either is done right." I mean that facetiously of course. Management and leadership are indeed two separate disciplines---but they need each other.

My point is that in order to manage well (assuming one is managing people), leadership skills are essential. And in order to lead well, knowlege of project management techniques (or at least the assistance of someone with that knowledge) is critical if those bold visions are to be realized safely.

In that sense, leadership and management are two-halves that make up a whole.

For an excellent writeup of the need for leadership, not just management, read on ...

Bold Vision Business!

FBI Launches New Case File System Project; For the Second Time

As reported in Computerworld, the FBI has hired Lockheed Martin to lead an effort to create a $425 million case management system called "Sentinel." Their current case management processes are antiquated and mostly manual.

The catch is that they tried this before and failed. The prior attempt was abandoned last year after four years of effort and $170 million spent. The problem? High turnover of key managers and inadequate staffing of the project.

Here's a quote from the article...

"According to a 91-page report released last week by the U.S. Department of Justice's inspector general, the Virtual Case File effort failed partly because the FBI's IT project management office seemed to have a revolving door. Virtual Case File had "15 different key IT managers over the course of its life," the report said. "

Apparently, some of the hardware and networking from the prior attempt will be used, so it wasn't a total loss. And with this new attempt, they'll be using a more open architecture. However, they still haven't fully staffed their PMO (a concern raised in the inspector general's report). Hopefully history won't repeat itself.

Here's the full article...

FBI Shifts Into High Gear on $425M Case File System

New IT Security Courses for Project Managers

Alan Calder and IT Governance Limited are now offering two courses for those saddled with trying to bring their organization up to the new ISO 27001 security standard.

One is a one-day introductory course for IT managers, project managers, and business managers. The fact that it's priced at about $720 and explains how to implement the standard in-house without expensive consultants makes it very appealing.

The other is a three-day intensive class that covers the whole implementation process and framework.

Both courses are in London in June.

For those that are managing IT security initiatives, these courses look well worthwhile.

Project Planning Not All It's Cracked Up to Be

OK, everyone relax, I haven't lost my mind. Of course planning is important. But, as I've been saying for years, circumstances change the minute a plan is put on paper and a good project manager needs to expect uncertainty and know how to deal with it when it arises.

There's a great article in Projects@Work by Roger Bly that supports this approach. Bly talks about how project managers must manage the entire end-to-end process, and recommends taking a collaborative approach, using tools that enable frequent two-way communication and the ability for resources to keep the plan current and reflective of reality (something I completely agree with).

Here's an excerpt...

"A collaborative project execution application can make this process a reality in organizations of all sizes by allowing project teams to successfully tackle multiple concurrent projects. Projects are no longer constrained by static plans produced and updated only by project managers.

A project execution approach also frees project leaders from the mundane work of updating project plans, collecting progress information and reformatting information into status reports. Project plans can be collaboratively built and updated by the project team, often by reusing collateral, deliverables and templates from previous projects."

Far too often, a project manager will create an elaborate plan, and struggle to keep it current, ignoring the real issues that occur during project execution. If the team is trained to contribute frequent updates of remaining time (and any changes to the plan), the project manager can spend more time leading and monitoring as opposed to administrivia.

Of course, another easy way to accomplish this is to update the plan and percent complete collaboratively at a weekly meeting on an overhead projector, but it's ideal if the resources can update their own activities electronically.

For more about the need to focus on execution and communication, read the full article...

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

Project Failure Case Study; Maine's Medicaid System

Talk about a project disaster. As reported in an excellent article in CIO Magazine, the Maine Medicaid Claims System project is a case study of a project gone awry.

The project was undertaken to switch from their legacy systems to a new web-based system to process Medicaid claims and facilitate HIPAA compliance (Health Insurance Portability and Accountability Act of 1996). As a result of the failed project, Maine is now the only state in the union not in compliance with HIPAA.

System problems led to many claims ending up in limbo, leading to hundreds of calls from health care practitioners, nearly 300,000 patients being turned away, several dentists and therapists going out of business, and destroying Maine’s finances and credit rating.

So what went wrong?

Mistakes included the following:

• Deciding to develop an entire system from scratch using unproven technology, while other states built a front-end onto their legacy systems
• Caving to pressure from management to meet tight deadlines with inadequate resources instead of pushing for a realistic plan to begin with
• Failing to notice why other bidders either didn’t bid or came in way higher (a sign that the schedule was unrealistic)
• Hiring a vendor with no experience in developing Medicaid claims systems because they were the lowest bidder
• Not having a Medicaid expert on the team, leading to errors in judgment
• Underestimating the time needed to meet with subject matter experts
• Competing with another major initiative (a department merger) for executives’ attention and resources
• Skipping project management basics (including piloting, adequate end-to-end testing, staff and user training, etc.) due to looming deadline pressures
• Failing to stop, regroup, and analyze the risks
• Taking a “big bang” approach to cutover with no contingency or backup should something go wrong

Management’s response, of course, was to switch program managers, and issue stronger demands to have a smooth system, but none of the changes or demands made much of a difference. Consultants were brought in to prioritize the many problems, but still, the complexities proved too much. It wasn’t until a Medicaid expert was brought in that things began to gel.

Like many project failures, it’s easy to point to the project management (and certainly there are many shortcomings there in this case), but the organization must share the blame as well if it insists on unrealistic deadlines and leads by fear (fear of shareholders, fear of competition, fear of management, etc.). None of these variables can make an unrealistic schedule more realistic.

It's really very simple. Either adequate resources must be committed, the expectations lowered, or a more piecemeal approach taken (or all three, if applicable). In any case, the schedule must be realistic and risks need to be managed.

Here's the full article. It's well worth reading, as are the reader comments.

Maine's Medicaid Mistakes - Editorial - CIO

Project Management Fundamentals Course ...

Upcoming project manager fundamentals course ...

... "Elon University Executive Education announces Fundamentals of Project Management -- a three-day, instructor-led training class designed to introduce participants to the basics of the project management discipline. The class will be held on May 23 - 25, 2006 at the Moseley Center on the Elon University campus. " ...

Via Elon Univ: Fundamentals of Project Management training class to be held in May ...

Organizational Project Management; Why Should CEOs Care?

Paul Dinsmore and Pedro C. Ribeiro's article in Chief Project Officer talks about why CEOs should care about project management. He lists several areas where project management can directly impact the bottom line, including working capital, sales growth, and profit margins.

People are beginning to realize that project management is much more than managing individual initiatives; it's about transforming everything an organization does into a project-based approach.

In the article, Celina Antunes, CEO South America Region for Cushman & Wakefield Semco comments:

“For decades, project management has been a discipline in engineering, construction and other industries, where a key management skill has always been the ability to complete a job on time and on budget. Yet it's only been in recent years that the discipline has moved to its current status as one of the leading reasons for success in some of the world's best companies. When you need an outcome done right, on time, and within a budget, you definitely need project management to assure results”

Of course, to be truly effective, this requires a strong committment to becoming a "learning organization." Here's an excerpt from another quote, from Robert Cook, former CEO Latin America for Unisys Corporation:

“The importance of excellence in project management could not be over rated. I would guess that all of us as senior operations people have been involved in projects that have created shareholder value and those - that have reduced
shareholder value... We need to be in a continuous learning process. A well structured lessons learning process in project management is key to seamless execution and ensuring that the direction of the project is correct from the beginning of the effort”.

For the full article, read on...

Chief Project Officer: Why Should Project Management Matter to CEOs?

Software Projects Doomed From the Start; Blame the Stakeholders

OK, maybe this doesn't top the skateboarding dog (see yesterday's post), but here's an extremely compelling article from the Defense Acquisition University (DAU) on why most software projects are doomed to failure.

Thanks to PMForum for posting this in their news section.

The article states that most software projects come nowhere near their original baselines (although they may come closer to approved revised baselines). It says that stakeholders and the organizational environment, more so than lack of project management skills, bear much of the blame. Here's a quote:

"No amount of training in the technical skills of program management will overcome the simple truth that, as a PM, you cannot make people do what you need them to do. This is the root cause of many software-intensive program failures. Stakeholders often cannot agree on priorities, refuse to standardize business practices, take off on their own proprietary solutions, or simply refuse to participate in the program."

The article also says that the original plans are usually unrealistic to begin with, and underestimate the organizational challenges. It says we make matters worse by holding project managers accountable without giving them the necessary support to be successful.

"... Most expectations of contemporary programs are unrealistic. The cruel reality is that we train PMs and drop them in an organizational 'shark tank' that opposes many of the principles they have just absorbed in their training. Program managers often find themselves in a superfluous role, accountable, yet powerless. "

The article proposes a system of observing stakeholder behavior and rewarding and discouraging behavior as appropriate. Of course, an organization must recognize the problem and commit to doing something about it.

Senior leadership must be actively involved in fostering the changed behaviors. Otherwise, software projects will continue to be underestimated and mired in conflict, despite the best training, the best EPM tools, and the best processes.

I highly recommend reading the full article, "Irreducible Truths of Software-Intensive Program Management", by David Cottengim.

PMFORUM, Connecting the World of Project Management PMFORUM Breaking News: MOST SOFTWARE PROJECTS ARE DOOMED TO FAILURE ACCORDING TO PENTAGON PAPER

Laws Of Project Management

Although I found this article under jokes at funnymail.com, some of these are no laughing matter. A few of my favorite "laws" of project management include:

1. No major project is ever completed on time, within budget, with the same staff that started it, nor does the project do what it is supposed to do. It is highly unlikely that yours will be the first.

2. The effort required to correct a project that is off course increases geometrically with time.

Corollaries:
a. The longer you wait the harder it gets.
b. If you wait until the project is completed, its too late.
c. Do it now regardless of the embarrassment.

3. Anyone who can work effectively on a project part-time certainly does not have enough to do now.

Corollaries:
a. If a boss will not give a worker a full-time job, you shouldn't either.
b. If the project participant has a time conflict, the work given by the full-time boss will not suffer.

4. Projects progress rapidly until they are 90 percent complete. Then they remain 90 percent complete forever.

For more Laws of Project Management see:
The 15 Laws Of Project Management

ERP Project: Keep Eye on Details ...

Firm publishes report on approach to challenging ERP business transformation projects. Current marketplace conditions are impacting the quality of ERP implementation talent even in the context of a strong methodology. This requires the client company to pay close attention to the project details. Be on the look-out for: Lack of transparency, limited bottoms-up planning to complement the top-down methodology, no iterim integrations with legacy systems to bridge gaps during the implementation, and missing current state analysis.

... "Based on its work helping numerous companies pull errant ERP projects back on course, DiamondCluster has identified circumstances that endanger projects and offers specific steps that can keep companies moving in the right direction. " ...

ERP Project: Keep Eye on Details: Via DiamondCluster: Red Flags Can Signal That ERP Integrators Are Off Course According to New DiamondCluster Report: Studies Show Many ERP Projects Still Run Significantly Over Budget and Behind Schedule. New DiamondCluster Report Explains Why and Offers Advice to Keep Efforts on Track ...

Project Risk Control vs Innovation

Winston Churchill once said, "The optimist sees opportunity in every danger; the pessimist sees danger in every opportunity."

As project managers, we are taught to focus on reducing or avoiding risk, but all too often we forget that a good risk management plan should include opportunities as well. Sometimes those opportunities will carry additional risks, but if the benefits are worth it, we need to exploit those opportunities. Certainly we can---and should---try to mitigate the risks, but the point is that in focusing on the dangers, let's not overlook the opportunities.

When framing a project, it's important to see for ourselves what the customer's situation is, and get engaged an an "opportunity assessment." As Tom Kelley of IDEO pointed out in The Ten Faces of Innovation, Henry Ford said that if he'd merely asked customers what they wanted, they would have said a faster horse.

Of course, not every opportunity will make it into the scope of the initial project, but at least there can be a plan to exploit it.

So, using Winston Churchill's axiom, should project managers be optimists or pessimists? I'd venture to say we need to be a little of both, and the right balance is the art of project management. For more on how innovation and project management can and should coexist, stay tuned for my upcoming post on the relevance of Tom Kelley's book to project managers.

Project Management Course ...

... "Project management course, 9 a.m. to 4 p.m., March 7, 14 and 21, Center for Research and Innovation, Bemidji State University. Three-day course will provide instruction in the management tools necessary to ensure successful project implementation and will cover topics including project selection, life cycle, scope planning, work breakdown structures estimating costs, execution and control and risk management. " ...

Project Management Course: Via Grand Forks Herald: LOCAL BUSINESS CALENDAR

Managing Global Projects; Don't Be a Tourist

Ladies first, No steamrolling, Swastika greeting cards....

No, I haven't lost my mind, and this isn't some weird form of free association. These are all examples of cultural misunderstandings that are pointed out in an insightful article from Computerworld.

It reminds me of that old series of TV advertisements with a "Don't be a tourist" theme (one example had Richard Nixon giving the "OK" hand gesture while getting off a plane in Latin America--and nearly causing a riot). Of course, I forget the product being advertised, so the ad couldn't have been too effective. But I digress.

In all seriousness, having done quite a bit of travel myself, I can vouch for the importance of avoiding the stereotypical American trait of steamrolling your ideas or values, or assuming everything works as it does here in the U.S. (yes, I realize not ALL Americans are like that, but a sad number are).

Better to engage people's input, and have them be part of the solution. A little bit of humility and cultural awareness (and, dare I say, learning at least a few phrases of a foreign language) goes a long way. It's especially important when managing projects that span geographic and/or cultural boundaries.

Here's the article from Computerworld (and just so nobody thinks I'm picking on Americans, the article shows that cultural misunderstandings are a global issue) ...

Culture Clash - Computerworld

Project Management Exam Prep ...

Upcoming PMP exam prep course ...

March 16-18: The Northeast Wisconsin Chapter of the Project Management Institute will conduct a three-day project management professional exam preparation course from 8 a.m. to 5 p.m. at Liberty Hall, 800 Eisenhower Drive, Kimberly. The course is designed to tutor attendees through the PMI Project Management knowledge areas and code of professional conduct with the focus of helping students prepare to pass the PMP exam.

Project Management Exam Prep: Via Appleton Post-Crescent: Business planner ...

Project Management Rules vs Common Sense: A Lesson From a Taxi Driver

Are You Talkin' to Me?


I was riding in a taxi today, and the driver told me a funny story. He said that when they went to Taxi Driver Courtesy Class, it was conducted by a police officer. The officer discussed the need to pick up every potential rider and not to bypass anyone based on appearances or convenience. One driver rightfully raised the question, "What if the person looks dangerous?"

The officer covered his badge with his hand and mock-whispered, "Then don't pick them up." Then he took his hand off his badge and said, "You must pick up every fare, no matter what their appearance is." The class, of course, roared in laughter.

The lesson is that common sense must always prevail over rules, and the same thing applies to managing projects.

Now, put on your best Robert DeNiro face and repeat, "Are you talkin to me? Are you talkin' to me?"

Agile Scrum Project Management; Applicable to All Projects?

I just finished reading Agile Project Management with Scrum, by Ken Schwaber, and the case is most compelling.

As we've posted here, Scrum is all about daily communication and short 30-day iterations focused on business value. No doubt it's a change from traditional project management, but it takes a sensible, pragmatic approach. As the author points out, Scrum is about "the art of the possible" and especially shines when dealing with complex initiatives (which most IT projects are).

While the book is geared toward software development projects, I found myself asking if this approach would apply to other projects, such as implementing packaged software, or even non-IT projects. I think the answer is a definite "yes." However, the first round may take longer than 30 days, depending on the complexity of the configuration and a hundred other variables.

Suffice it to say that time-boxed iterations focused on delivering some level of pre-defined business value at each iteration is the right way to go for most projects, and certainly most IT projects. Phased deliverables offer earlier payback, quick wins, and allow the flexibility of changing course in future iterations. That sounds like a win-win to me!

PMP Exam Prep Course ...

PMP Exam Prep Course upcoming ...

... "March 16-18: The Northeast Wisconsin Chapter of the Project Management Institute will conduct a three day Project Management Professional exam preparation course from 8 a.m. to 5 p.m. at Liberty Hall, 800 Eisenhower Drive, Kimberly. The course is designed to tutor attendees through the PMI Project Management knowledge areas and Code of Professional Conduct with the focus of helping students prepare to pass the PMP Exam. " ...

PMP Exam Prep Course: Via Appleton Post-Crescent - Business planner

Scheduling is Dead, Bring on Chaos; So Says A Foremost Scheduling Expert

Project scheduling has no future whatsoever, and this comes from no less than Murray Woolf, the Managing Director of the PMI College of Scheduling's Scheduling Excellence Initiative (SEI).

This article, posted at PMForum is one of the better ones I've seen in a while (possibly because it's aligned with my philosophies). The premise is that, in today's day and age, the industry is headed toward more of a "give the people objectives and let 'em work it out" philosophy, which is completely opposed to the old "build a detailed schedule and make 'em follow it" mentality.

This is completely aligned with a value system that I've long subscribed to (and had posted on here at PMThink), and that is: To foster passion and accountability, we need to provide:

- Autonomy and Trust
- General Guidance and Principles
- Support and Removal of Barriers

This, of course, must be supported by having clear objectives.

Through all this, we also need to send a message that results are more important than blindly following rules. This doesn't mean that we needn't have processes, as people need a system in order to achieve consistent results; merely that we should give project managers the freedom to bypass certain processes if it's necessary to achieve good results. "Good" is the operative word here. Just meeting a date is not "results."

I believe that Mr. Woolf's article endorses my approach, and acknowledges that the following is where the future of project management is:

More organized chaos than it is controlled components.
More project facilitation than it is project scheduling.

This doesn't mean that planning isn't important either; merely that the act of planning shouldn't be confused with rigidly following the plan/schedule. As Dwight D. Eisenhower said, "Plans are nothing; Planning is everything."

As it is, and as Mr. Woolf rightly points out, project managers and "schedulers" are so bogged down in details and administrivia that they become more project reporters than managers. We need to observe where the future is headed and free project managers from the burdens of such fruitless details.

Instead, their efforts should be spent on adequate preliminary research, communication, facilitation, risk awareness, and other traits necessary to effectively manage a project.

For the full article, which I highly suggest reading, see Mr. Woolf's paper below...

PMFORUM, Connecting the World of Project Management - Papers

Project Portfolio Management: Monitor Investment Value ...

Patrick Durbin, Planview CEO, explores the integration of IT strategic planning and project portfolio management to drive the value from information technology investments. Alignment of IT with business strategy creates visibility to value opportunities. Portfolio-based investment analysis enables objective selection of the best mix of investments. And, active management of benefits increases the likelihood of realizing the targeted value. ...

... "Discretionary, strategic investments to grow the business or transform the business can take years, involve thousands of person hours and cost millions of dollars. Organizations must carefully choose which of these investments to pursue and then regularly monitor them on a periodic basis to ensure that the business value is still relevant. " ...

Project Portfolio Management: Monitor Investment Value: Via DMReview: Chart Your Course to Strategically Align Business and Technology

Remote project team communications

For anyone who's been the only teleconferencee into a physical meeting, you'll know the sense of frustration when someone says "I'm just passing out copies of this document...". Of course, without the document you were unable to participate or contribute to the topic. This is ineffective use of your time whatever the topic. If this is a project meeting, the danger of having a team member being disconnected is in rework, missed deadlines or poor quality.
The example above is just one instance of uneven availability of information. For any meeting, it is critical that you do the preparation to make sure that communication is effective. And one basic requirement is to make sure that everyone has equal access. If there are reference documents, make sure they are distributed ahead of time - early enough for them to be read before the meeting. If there are functions to be demonstrated, make sure that remote desktop display such as WebEx is available.
This document gives some tips for working with distributed teams.
Project Management Tips and Techniques - Managing a Dispersed Project Team

Project Perception is Reality; Don't Let 'em See You Sweat

Pay no attention to that man behind the curtain!


When it comes to project success, perception is more important than reality. That's not to say you should lie or cover up anything, merely that your stakeholders don't need to know (nor do they care about knowing) all the little difficulties and issues you're experiencing in the project.

Keep project status reports brief, listing a short status, the key milestones, the top 3 issues, and what's being done to address them. Paint a positive picture of events, even regarding the issues being addressed. Project team members and stakeholders must feel that the project is well under control.

Of course, if huge barriers exist, or major issues arise, address these immediately with whatever team members and/or managers you need to resolve the issue. Management needs to know these things. But if you reach a point where you must communicate bad news more broadly, try to focus on the positive side of things (everything has a positive side if you look hard enough). Public relations experts have taken this approach for years with great success.

Even a project where it makes sense to cancel it, maybe because it no longer will bring the expected benefits, should be seen as a good thing, as it means the system is working. Remember, keep it positive!

Project Manager Tip: Do What You Do Best, Delegate the Rest

Dammit Jim, I'm a doctor, not a project administrator!


One thing project managers must come to terms with is what they're good at and what they're not. That's not to say you shouldn't build skills in deficient areas, but nobody can be good at everything. The key is to delegate what you're not good at. This was one of Peter Drucker's key points in The Effective Executive, one of the best management books of all time.

For instance, to really focus on the leadership of a project, delegate the project accounting and administration to a "project control specialist," something we've suggested here at PMThink for a while now. A tip from "The Motivational Manager", from Ragan Management Resources (fast becoming one of my favorite newsletters), is to even delegate employee regonition if you're not good at it or too tied up to do it effectively.

Employee recognition is such a critical part of project success, and so often overlooked. It should ideally be done by the project manager, or better yet, senior management. But as a last resort, why not make employee recognition a formal part of someone's role on a project team or in a department. Of course, even then the recognition should be acknowledged by the overall manager.

Food for thought.

Results vs. Process - Revisited

The other day, I posted a blog on results vs process. The conclusion I came to was that for projects (which are by nature of limited duration), it was more important to do what it took to assure good results than to blindly follow process.

Of course, the definition of "good results" must be agreed upon. I also added the caveat that this does not apply to processes that must be observed to assure adequate results.

While I still fully believe this approach is true as a guiding principle for project managers, I've come across two good arguments in defense of process in general:

1) Results are often uncontrollable, while processes (if maintained) can at least assure more consistent results over the long haul. Uncertainty is a given, and good processes will allow for that and plan for that.

2) Conflict should always be expected, and should be used to improve processes rather than be seen as an impediment to results. Conflict is a good thing. Unresolved conflict is not.

My clarification of "results over process" is this:

• When defining processes, don't make the processes so heavy and bureaucratic that they impede results.
• Introduce processes slowly. Don't expect overnight results; Follow a maturity model and strive for continuous improvement.
• Relentlessly search for less invasive ways of accomplishing control.
• For each potential new process, use the"Five Why's" (asking "why" five times until you determine if the process in question is really needed). If in doubt, don't add it.
• Allow room for people to make decisions. If a principle will work just fine to help keep people on course, then don't institute an unnecessary process. Not everything can or should be "process-ized." Generally, aim for principles over processes wherever possible.

I do think Toyota has it right. By focusing on long-term results (i.e. continuous improvement) over short term results, continued success is more assured. By we don't want to unnecessarily impede short term results either. We can walk this balance by keeping our processes lean and giving project managers the freedom and confidence to do what is right to successfully deliver a project. People are ultimately our best asset.

VOIP Project: Voice-Over-IP ...

The VOIP transformation project is relatively high-risk: newer technology, questionable scalability, increased cultural change, and impact to a critical business function: communications. J. Nicholas Hoover discusses the pitfalls of a voice-over-IP phone project

... "Anyone thinking a switch to a voice-over-IP phone system will be smooth and easy should remember Ruth Harenchar's ruby-red nail polish. At the Hobart West Group, where Harenchar is CIO, the company's VoIP project required tough decisions, like whether to spend money training existing IT staff or hire expensive consultants. It meant learning to live without certain common telecom features in order to get the savings the company wanted. And it involved helping employees through the culture shock of replacing the familiar ... " ...

Via InformationWeek | Voice-Over-IP | VoIP Gotchas ...



Here are some relevant references on VOIP implementations:

Via NetworkWorld: The ROI of VoIP: "When it comes to VoIP, most network managers are satisfied that the technology works. The challenge is developing cost analyses: What will the new technology cost to roll out and support, and what benefits can companies expect to reap? "

Via NetIQ: VoIP in Action: "OK, you've moved beyond the deployment stage of your VoIP project. Your first group of VoIP phone users are happy and you've got high levels of availability and call quality. Now what? In the management stage, you need to keep those users happy with consistent availability and high call quality. "

Managing VoIP Implementations Effectively: "Voice over IP (VoIP) is the hottest telephony technology. Consumers and corporations are looking to reduce costs by deploying VoIP systems. The challenge, however, is that the technology is so new that few project managers have expertise in managing VoIP implementation. If you are interested in or responsible for implementing VoIP at your organization, this is the course for you. "

Results vs. Process; Which is More Important?

In the project management world, we've all been hearing about "process" for years, and of course most of us have been indoctrinated in PMI principles. And process is important, because it gives us a roadmap to follow and allows for continuous improvement (provided we learn from mistakes and tweak our processes accordingly).

But as the saying goes, the map is not the territory. Ultimately, in order to achieve results on a project, we need to know when to streamline certain processes, or even break the rules entirely, especially when faced with day-to-day challenges.

Companies like Toyota live by processes (even over short-term results), and do very well. But that is organizational strategy -- and a good one at that. The idea is that if processes are monitored and improved over time, then long term results will ultimately be realized. With project management, on any given project we cannot afford to wait years to see the fruit of our process improvement labors pay off. We're on a limited timeline, and must show results.

Granted, we still must conduct lessons-learned sessions and regularly revise gaps in our project management process (constantly looking to streamline), but from a tactical project management standpoint, results must come first.

This is why I conclude that, when it comes to managing a project, results are more important than process.

But there's something even more important than results, and that's people.

Ah, but that's the subject of another blog (to paraphrase the ending of the film, "The Jungle Book" -- the Sabu version, not the Disney cartoon).

Project Estimating; Triple Constraint Must Stay Firm

Here's a great article from TechRepublic about project estimating and forecasting. It cautions that one of the worst things to do is to try to force a project to fit within an arbitrary management deadline. That means project managers must defend the right plan or suffer with poor results.

A properly estimated project must be based on planning, and be managed to the triple constraint of scope, time and cost (and of course, at PMThink we've discussed other potential variables, such as quality, risk, customer satisfaction, and more).

Here's TechRepublic's advice to CIO's:

Project managers talk about a project’s “triple constraints” of scope (work), time (schedule), and cost (budget)... For the team to make decisions that are closely aligned to the way you would like them to be made, you must clearly state the project priorities. There’s no such thing as “all three variables are equally important.”

Read on for more details or proper estimating and forecasting...

How to accurately estimate and forecast in project management

Project Management Heresy; Is Gold-Plating Really that Bad?

PMI has drilled it into our heads for years about the perils of gold-plating, and how we need to focus on just meeting requirements, yada yada yada.

Yet, when I think back to the most exciting work that I had done (years ago), it was when I had met with a client (a customer service specialist) to look into a simple request to develop a few reports. She needed this so she could have more information readily available to solve customers' problems. I watched this person work for a while and felt immediate pain at what she had to go through to resolve customer problems and take orders over the phone.

She had to make a zillion phone calls and run back and forth to the plant flooor to see the status of an order, most of the time calling the customer back hours or days later. I went back to my team, and we decided it would be just as easy to give her an online "dashboard" right from her primary order inquiry screen (this was before dashboards were popular).

From there, she could see inventory allocation, and at what point material would be in stock to complete the finished products for the order, as well as other related info. She could track the customer's products from order through manufacturing. This saved her daily walks to the plant floor. Not only that, she could now address her customers' problems while they were on the phone!

Upon seeing the impact this made, we then asked if she'd also like to be able to look up shipping information, delivery tracking, and accounts receivable as well, and of course she was overjoyed. The system revolutionized customer service for this company.

One might call this gold-plating, but I call it excitement. We were excited about making a huge difference in the ability of the client to solve problems, and the client was excited to offer this benefit to her customers. Of course, I first watched the client in action so I could easily tell what was needed, so this was still a pragmatic approach.

As long as innovations have a practical use, then it's not really gold-plating. It's gold.

In our relentless pursuit of "meeting requirements" and "attaining better efficiency", let's not forget that passion and excitement can energize teams and customers, and often leads to further innovations. Above all, it leads to action and movement! Ironically, this critical mass can increase throughput even better than traditional efficiency and scheduling methods. Bottom Line: We need to bring passion and creativity back into the workforce!

Matrix management for Project Teams

Reading Kerzner recently on project management maturity, an important principle was reinforced - effectiveness of the organisation in matrix management of project team members is a requirement for level 3 maturity. In this context, matrix management usually refers to dual management of individuals making up the project team. The first, traditional management line is the functional one - e.g. engineering, procurement, design, accounting. The second is the project organisation under which the project manager directs the resources for the effective execution of the project to deliver the product - and sometimes appears under the title 'product management'.
Since a project is, by definition, temporary in nature it can be difficult to visualise a permanent matrix organisation since only the functional management dimension is permanent. Worse, there may be multiple projects on which team members would work so there could be multiple reporting lines for a team member. If you add in recent trends towards individuals having more than one functional responsibility the situation can be terribly complicated.
Looking for some additional insight into the issue, I came across this paper from the Journal of Management. It describes the continuum of matrix management styles and discusses the influences at work. One really important point is that the success of any level of matrix organisation depends on the quality of communication across the different management dimensions. Of course - aren't we always crying out for effective communication? Well, yes. But this is more - it's not only sharing information, it also implies the effective receipt and approeciation of the communicated information. There's more gold in the article and it deserves reading in full.
Journal of Management: Cross-functional structures: a review and integration of matrix organization and project management

PMI Lowers Passing Score on 2005 PMP Exam; Breaking News

Point Advantage, a PMI education provider of PMP exam prep courses, project management training programs, and learning tools, announced on their website that PMI has lowered the passing score on the new PMP exam from 81.7% to 61%.

We reported the other day that PMI was reviewing the exam questions, as they usually do after releasing a new exam, and this is the result. Of course, they'll retroactively adjust the scores of those who have already taken the exam.

More details below on the Point Advantage site...

Project Management Certification Training PMP Exam Prep Courses

Phased Approach Critical to World Class IT Governance; Nice 'n Easy

Fred Gattelaro from Pacific Edge has an excellent article in Computerworld on the importance of introducing IT Governance in phases, not as a big-bang approach.

I can say with certainty that this is sound advice.

He suggests focusing on each of the following three phases, one at a time:

• Creating Visibility -- First Understand What Exists
• Improving Execution -- Integrating New Processes
• Optimizing Results and Continuous Improvement

Just as with introducing any new fundamental change, the organization needs to progress through a maturity model. And, for IT Governance, this one's as good as any.

Too many organizations try to do it all at once, and it becomes a real credibility problem. Read on...

Charting a Course to Achieving World-class IT Governance, One Step at a Time - Computerworld

PMI Reviewing New Exam Questions; Clarification of Rumors

Rita Mulcahy at RMC Project Management (and creator of an excellent PMO Exam Study course) posted a clarification on her site of PMI's recent announcement regarding the review and possible revision of new exam questions.

PMI's normal process is to review the performance of questions after new exam is released, and as such they are doing it with this exam. They may remove or rewrite certain exam questions as needed, and would adjust the score of those who have taken the exam accordingly.

Apparently, rumors have gotten out of hand, and Rita clarifies them below...

Clarification of PMI Announcement Regarding PMP Exam: Are the Rumors True?

Earned Value - why does it have to be so difficult?

This paper from the recent PMI-SAC conference describes how to apply a simple approach to Earned Value Management for IT Projects. It starts with the question 'why is EVM so little used?' and puts forward 4 of the more common reasons. The author goes on to describe what was originally used as a paper based method. It exploits the natural structure of IT projects, frequently formalised in some form of stage gate process. Industry norms for the relative breakdown of costs by stage and activity or phase within the stage are used to compare to actual costs.
This approach implies that you do not need a detailed bottom up cost and activity tracking in order to calculate the earned value. Of course, it would mean that you don't have much earned value information during phases and breaking the phases down into very small units may stretch the applicability of the statistics used at the outset.
Of course, the method still requires some work, project structure and some organisational discipline. This can be one of the most difficult of the original four reasons to address - Because sometimes management doesn't really want to know!
Earned Value Management for IT Projects

IT Strategy: Integrate Mobile Technology and Workforce Mobility ...

Nokia offers advice on strengthening IT strategy by enabling workforce mobility through integrated mobile technology. ...

Via Nokia: Nokia identifies five phases of workforce mobility to help companies gauge and guide their use of mobile technology: Key stages help companies measure the value of their own approach to mobile technology and outline the building blocks necessary for a successful strategy ...

... "The five stages start from an organization's idea of mobile technology and the integration of mobility into an overall IT strategy, and play out the course of mobile technology to the point where the way business is done is forever changed. That shift is still ahead, but in between the two extremes lay several phases many companies can identify with now - from starting to mobilize workers as more of a matter of convenience, to taking the notion of mobility for granted and focusing on increased productivity. Integral to getting the most from mobile technology are several building blocks Nokia has identified that companies should keep in mind when developing and implementing a mobile strategy. These pieces consist of much of the same components that make up any IT strategy, including leveraging existing assets and infrastructure, addressing diverse user needs, and ensuring security, scalability and support is in place. " ...

IT Balanced Scorecard BSC: On IT Governance Roadmap ...

Measuring the performance of IT governance, the project management office (PMO), and individual projects is critical to understanding your current capability and to chart a future course of action. Shashwat Singhal explores the IT governance roadmap and the use of an IT balanced scorecard (BSC) to ensure that decisions are made in the interests of shareholders. ...

IT Balanced Scorecard BSC: On IT Governance Roadmap: Via Express Computer: Implementing IT governance ...

... "The IT balanced scorecard is an important mechanism for managing and aligning IT. Therefore, step 11 of the implementation road map refers to the establishment of an IT balanced scorecard. " ...