Project Forecasting: More Lessons from Driving

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

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

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

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

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

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

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

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

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

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

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

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

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

Project Management Delays Are Sometimes Good

There's an interesting article on Computerworld about the need to procrastinate more in project management.

Huh? No, really. In reality, it's about slowing down the early stages of a project in order to get the true client needs and requirements understood and prioritized. It also suggests procrastinating by moving some complex items later in the plan to accomplish some quick wins early.

Maybe good things really do come to those who wait.

How to Manage by Procrastination

Getting Projects Off On the Right Foot: The Pre-Flight Checklist

Something you don't hear much about, but is a critical success factor for projects, is what I call the "pre-flight checklist." As projects are completed, not only is it important to review lessons learned, but it's vital to have a checklist that can be updated as a result. This checklist would be the first thing a project manager would look at upon undertaking a new project.

This is especially true for agile projects, where adjustments are constantly made based on user feedback. Of course, not everything would go on the checklist, but any item that could save time later on a future project is well worth adding. Why reinvent the wheel?

If warranted, there could even be a checklist for various types or categories of projects.

This checklist is different from a pre-project assessment (another underrated tool), where preset questions pertaining to objectives, risk, value, organizational alignment, and more, can be asked.

As the adage goes, projects fail at the beginning, not the end.

The Five-Minute Project Manager

Sometimes the best project management tips come from other fields, such as this free "Five Minute Guide to Project Management" from a creative arts website.

Simple, to-the-point, and yet quite effective, this brief guide reminds us of the basics that so often get forgotten in the midst of earned value, critical path, and other favorite topics of PM nerds.

As the article discusses creating a project plan and formally managing subsequent revisions as part of a "contract" between you and the sponsor, let's not forget the importance of defending the right plan.

I was having lunch with a group of CIOs the other day (following a presentation I had done), and all agreed that the number one killer of projects was an unrealistic plan, often agreed to under duress by an intimidated project manager.

Several CIOs present shared success stories of making a case to other senior executives by way of a high level project schedule, outlining the steps needed to achieve results. Often, that's all it takes. Some people I've spoken with have had some luck backwards-scheduling as needed from a given target, either to demonstrate the futility of the desired target, or to raise discussion as to which items can be eliminated.

Anyway, I digress. Here's the article about the PM basics ...

creativepro.com - The Art of Business: Project Management for Creative Professionals

IT Project: Cutover Preparation

Mergers and acquisitions are common in today's markets. These corporate marriages often come with consolidation and integration. Eventually, information systems are consolidated. When systems touch customers, our risk antennae should perk up and we should prepare to minimize business impact. Preparation includes planning, temporary resources, a command center, practice through rehearsing, etc. Read about USAirways post-acquisition preparation for cutover to its common reservation system. ...

... "US Airways has been prepping for the mammoth IT project since the America West-US Airways merger closed in September 2005. " ...

Via Arizona Republic: US Airways IT Integration

Update: Via Bloomberg: USAirways Cutover Issues: "US Airways' kiosks at Charlotte and four regional hubs couldn't communicate with the reservation network for several hours after the systems were unified ... "

Project Management and Driving: Staying Tuned In

It had occured to me the other day that project planning is a lot like driving a car. If you constantly look down at the road in front of you, you won't be prepared if traffic suddenly stops or changes pattern. It's better to look out at the near horizon.

And if you listen to the radio for the traffic reports, you'll be able to avoid problems before you even see them.

It's the same with project management. We need to focus on the current planning horizon as far as we can reasonably see (usually we can only see three-to-six months out with any degree of accuracy). And it's equally important to stay "tuned in" through networking, reading what's happening in your organization and the world, visiting your customers and stakeholders, and practicing MBWA (Management By Wandering Around).

The more we're tuned in to internal and external activities that could impact the success of our projects, the better position we'll be in to address problems proactively and head off a traffic jam or a change in pattern.

Project Controller: The Project Manager's Best Friend

Halleluyah! Finally, there's an article saying what I've been saying for years. With projects becoming more and more complex, and leadership and stakeholder management requiring more attention than project managers have time for, there's a need for another role to manage the "control" aspects of the project.

This article by Robert Wourms on Projects@Work details how organizations such as State Farm have had success doing just that. Bring on the Project Controller. As a member of the leadership team for PMI's new standards for program management and portfolio management, I witnessed first hand how valuable this role was, as it freed the program manager up to actually lead the program.

The article shows how the project controller's role can include tasks such as:

1) Educating the team on processes
2) Facilitating Planning and Control sessions
3) Developing the project schedule
4) Controlling progress
5) Tracking and analyzing costs
6) Managing Issues, Risks, and Changes
7) Documenting and delivering status information

So what's left for the project manager to do? Plenty. Supporting this, the article offers a valuable table outlining the role of the project manager vs. the program controller. Read on...

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

Project Management Quotations

Here's a Wiki Quote site with a number of project management quotations. Despite some tired and well worn ones, there are a few gems in there, such as:

"The bitterness of poor quality last long after the sweetness of making a date is forgotten."

"Some projects finish on time in spite of project management best practices."

"The more ridiculous the deadline the more money will be wasted trying to meet it."

"The most valuable and least used phrase in a project manager's vocabulary is "I don't know"."

"The nice thing about not planning is that failure comes as a complete surprise rather than being preceded by a period of worry and depression."

"The project would not have been started if the truth had been told about the cost and timescale."

"You can con a sucker into committing to an impossible deadline, but you cannot con him into meeting it."

"All project managers face problems on Monday mornings - good project managers are working on next Monday's problems."

"At the heart of every large project is a small project trying to get out."

"Everyone asks for a strong project manager - when they get him they don't want him."

"Good project managers know when not to manage a project."

"If you don't attack the risks, the risks will attack you."

Enjoy...

http://en.wikiquote.org/wiki/Project_management

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.

Extreme Project Management: Reality Rules

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

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

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

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

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

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

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

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

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

IT Management Career Evolution: Flexibility ...

Flexiblity, coordinating, bridging, IT-savvy are all descriptions of the new (project) manager position in the information technology field. The "computer guy" career path is evolving. SIM finds these as requisite skills: planning, budgeting, scheduling, leadership, and risk management ...

... "But it's even more about IT-savvy project managers pegged to coordinate initiatives that bridge departments, where the dotted lines on the org chart are every bit as important as the boxes. " ...

Via Information Week: IT Manager Jobs Are Up 44% In 5 Years ...

Project Management Texas Style ...

The plan is made. The team is resourced. The baseline is set. ... Help the team have fun and focus. ... Project management inspiration from a great coach.

... "The game planning is over and I don't need to motivate this team. My job now is to settle them down so they can relax, have fun and focus when we need to focus. They can laugh and dance in the locker room but to win we need to balance being confident and focused. " ...

Via Every Game Counts: Texas Coach Mack Brown Blogs about the 3 Things that will Determine a Longhorns Win against the Buckeyes ...

PMOs and Resource Management: A New Role?

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

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

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

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

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

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

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

Einstein Project Management Tip #2: Think Flexible

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

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

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

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

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

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

Stay tuned for more Einstein project management tips.

IT Strategy: Comprehensive Outsourcing in Healthcare IT ...

Phoenix gains renewal of comprehensive outsourcing of hospital's information technology services, from the strategic to the tactical. ...

... "Under the renewed agreement, Phoenix, a national provider of healthcare information technology outsourcing solutions, will continue to staff and manage the hospital system's Information Services Department, which includes providing IT strategic planning, project management, network management, desktop support and data center management. Phoenix is also providing assistance with the implementation of Cerner's Millennium hospital information management system. " ...

IT Strategy: Comprehensive Outsourcing in Healthcare IT: Via Phoenix Health Systems: East Jefferson General Hospital Extends Comprehensive IT Outsourcing Contract with Phoenix Health Systems ...

PMO Process Primer

Last month, I mentioned a four-part series on Projects@Work about establishing PMOs. The first installment was on defining the role of your PMO up front.

Not sure what took so long for the second installment, but it's finally here and worth the wait (maybe it's a monthly series). This installment talks about the types of processes your PMO might undertake, and offers some food for thought with each process area. According to the article, a PMO might consider:

Project Processes (including demand management, approval, portfolio management, project/application lifecycle, and risk mitigation)

Analysis Processes (including business analysis, business case development, and process redesign)

Planning Processes (including planning and tracking, and capital planning and budgeting)

Administration Processes (including methodology management, training, tool development/ownership, and knowledge management)

To date, this series is an excellent primer on PMO startups. It's insightful and obviously written by someone who has had some varied experience in PMO implementation. I'm looking forward to the remaining two parts and will be sure to post the links here.

Kudos to the author, Ted Stephens, an associate principal at Intellilink.

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

PMO Success Story: A.G. Edwards Case Study

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

Some key lessons:

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

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

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

When Failure Is Not an Option - Editorial - CIO

Project Risks; Let's Talk About the Weather

When doing risk planning for your project, don't forget about seemingly off-topic risks, such as the weather, or the season of the year. It's an obvious concern if you're in the construction or farming industry, but in many other organizations, timing your project rollout to avoid quarterly closes, the company's peak season, or any other major seasonal events, can make or break your project.

I've heard of one popular confection organization that couldn't ship candy during Halloween because of a problem with their new SAP implementation. Bad timing. Another company that dealt with agriculture had to have a project completed before the summer growing season. They were smart enough to list that as a constraint.

The seasonal elements didn't just affect Napoleon in his failed Russian campaign (and many before and after him). It can affect those of us in business as well.

Project Management Lesson from Carpenters

No, not the brother and sister duet, I'm talking about real carpenters. There's an age-old axiom used by carpenters: "Measure twice, cut once." Experienced carpenters know that there's no turning back if you made a mistake measuring once the wood is cut.

This is good advice for project managers as well. Many errors, and many hours of rework, can be avoided if you take the time up front to do the proper research, planning, and risk analysis. It's well worth checking your plan twice, even though circumstances are likely to cause you to deviate from the plan. But even those risks can be mitigated with proper research and meditation up front.

Just like carpentry, the later mistakes are caught, the more costly and devastating they are likely to be. It's better to spend a little extra time up front on your projects to increase the overall speed and success of the project.

IT Strategy: Consulting Growth Rates Upbeat ...

Strategic planning consulting services are on the rise ...

... "Technology buyers spend more than a quarter of their project-based budget on IT strategy consulting and this service will see a growth rate twice that for business transformation consulting ... " ...

IT Strategy: Consulting Growth Rates Upbeat: Via Silicon Republic: Irish IT services spending to rise in line with EU ...

Project Management vs. Leadership: Is there Really a Difference?

Occasionally, I'm asked the question, "What is the difference between project management and leadership?" My answer is always the same, "Nothing, if they're both done right."

At their core, both project management and leadership are about leading people to achieve objectives.

Formal project management offers some tools for effective scope management, planning, scheduling, monitoring, and risk management, that increases the likelihood that the objectives will actually be met.

Likewise, general leadership is about setting strategy, communicating a vision, and inspiring people to do their best.

In other words, a project management approach can help leaders achieve their vision, and leadership skills can help project managers insure the success of their projects.

Neither one is fully effective without the other. Good leadership requires a deliberate approach, and good project management requires strong leadership. I'd venture to say that if one is failing, it's probably lacking the other.

Just some food for thought. It may seem like common sense, but there are those who think that the two are mutually exclusive.

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

10 Deadly Sins of Software Estimation

Steve McConnell, author, pioneer in the Rapid Development movement, and founder of Construx, a software consulting firm, has done it again.

His latest book, Software Estimation: Demystifying the Black Art, is aptly titled. Poor estimation (whether due to oversight or pressure from management) is one of the leading causes of project failure. McConnell has created a comprehensive, but easy to understand, software estimation "bible."

Of particular note is his "Cone of Uncertainty" diagram, which illustrates in a simple graphic the importance of catching defects proactively, and planning and analyzing risk continuously throughout a project (something I've always touted, and suggest in my own book).

Below is his insightful (and right on the money) presentation on the "10 Deadly Sins of Software Estimation" (in PDF format) ...

Link

Project Management: Olympic Proportions ...

Planning for the Olympics - high intensity project management at its best - with a lasting legacy ...

... "The Turin Winter Games gave us good glimpses of the scale of Olympic project management, the Melbourne Commonwealth Games the feel for a summer multi-sports event on a larger scale than Turin, and lastly Beijing, where for the last few days, we have had a chance to glance down the telescope to London in 2010, two years out from our spectacular Games. " ...

Project Management: Olympic Proportions: Via Telegraph: No flights of fancy when realising Olympic dream

PM Software Preview for OpenSource Desktop: KPlato ...

Preview available for open-source project management software ...

... "Technology Preview of a New Project Management and Planning Application: KPlato: KOffice 1.5 is the first official release to include KPlato. KPlato is a project management application that allows users to control project schedules and resource use. It is included in KOffice 1.5 as a technology preview and full functionality is expected for version 2.0. With this release, KPlato already offers various charts (gantt, pert), scheduling capabilities, calendars, resources, tasks and subtasks, detecting critical paths and resources as well as generating a work breakdown structure. KPlato can also be embedded into other KOffice applications. " ...

PM Software Preview for OpenSource Desktop: KPlato: Via The KOffice Project: KDE Ships New Release of Major Enhancements to Free Integrated Office Suite ...

Project Management Ain't What it Used to Be

There's an excellent article in Computerworld about how project management has evolved in the last few years to be much more than the traditional planning, scheduling and monitoring role it used to be (in some circles anyway).

Today's project manager, according to the article, must demonstrate strong business acumen, political savvy, cultural awareness, and soft skills.

A project manager today must be confident discussing a business case and benefits with senior management, negotiating the shark-infested waters of organizational politics, leading offshore resources, negotiating with vendors, resolving conflicts, and much more.

In other words, a project manager must be more of a mini-CEO than a scheduler or team leader. The implications are that a whole different skill set is required.

Here's the full article. It's well worth reading..

The New Project Manager - Computerworld

April Podcast from Jerry Manas

In this month's podcast, I discuss the importance of speed, and how to balance it with adequate planning.

Learn what can happen with even the slightest delays, as well as how to reduce resistance, increase urgency, and focus your resources.

Speed is the second of Napoleon's Six Winning Principles that I cover in Napoleon on Project Management. Last month, the topic was Exactitude.

Project Management Haikus

Just saw a list of Project Management Haikus from Everett Rodriguez on AllPM.

Hmmm. Maybe I'll give it a go. How 'bout:

My estimate's done
It's too bad it cannot meet
The sponsor's end date

Hey, that's not too bad. Maybe I'll try another.

My EPM tool
Can't calculate NPV
So I'll use Excel

I'm having too much fun here. OK, two more...

No one can tell me
Why I'm losing sleep at night
Over my S-Curve

and, finally....

They need more features
Why didn't they tell me this
During Scope Planning?

Better quit while I'm ahead (behind?). For Mr. Rodriguez's Haikus, see below.

Project Management Poetry: Haikus by Everett Rodriguez: AllPM 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 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

PMO as a panacea?

It seems that everywhere you turn, someone is recommending a Project Management Office as the solution to an organisation's project management woes. This 2003 article from CIO magazine makes a familiar point and provides some statistics that still have validity. Office Discipline: Why You Need a Project Management Office
The reason for bringing up the topic again now is that I recently came across a situation where a client was planning to implement project management tools - and to leave the project managers to use them as they saw fit.
McHardy's conjecture states that 'for business processes, whatever is not deliberately held together will fly apart'. In project management process terms this applies when artifacts - tools, procedures, templates, guidelines, etc. - are made available without any mechanism for coordinating their use. This is the 'discipline' referred to in the article. Without