2010 New Year’s Resolutions: Project Management/PMO

Along with the holiday festivities, the last half of December turns everyone’s thoughts to New Year’s Resolutions. If you adopted any of our project management resolution suggestions from last year, please leave a comment and let us know how that worked out for you. And, if you haven’t taken our survey about project success, please do. It will take you only 5 minutes, and we’re looking for both IT and business perspectives.

For 2010, we’re expanding the scope of our resolutions to include a few PMO resolutions as well. (Don’t worry, we’ve filed a change control request and had it approved by the proper authorities!) We approached 2009’s resolutions with an eye toward cost reduction, based on a grim IT budget outlook. 2010 looks like it will not see further cuts, with most companies either keeping budgets in line with prior year, or boosting IT spending by a modest 4-6%.

In this budget context, it’s still wise to consider ways to work smarter, not harder, and tighten up the alignment of all of your projects with the overall strategy of the business, realizing that the strategy often changes over time.

So, without further ado, here are our 2010 Project Management/PMO resolutions:

1. Writing up your meeting minutes is not as critical as limiting the minutes your team spends in meetings. Don’t get me wrong: published meeting notes are important, and they should still be distributed within 24 hours of each working meeting.  The following mental exercise will bring home the importance of running tight, efficient meetings:

1. Count the number of meeting attendees.

2. Multiply by the length of the meeting in hours.

3. Multiply by the number of meeting occurrences over the project lifespan.

4. Multiply by a fully burdened hourly rate.

A weekly internal status meeting for a year-long project could be adding significant cost to your project. Limit your agenda to the essentials: It’s not so important to review what everyone has done or what went well. Use the meeting time for resolving issues and managing exceptions.

2. Revisit the charter for your PMO and make sure it serves the business, and does not ask the business to serve the PMO. PMOs that exist to enforce consistency and police compliance with a methodology often end up slowing down project execution instead of enabling project success. Standardize project plan templates at the highest level necessary for tracking milestones across projects, and let individual project managers develop work breakdown structures within that framework, to a level that suits the needs of individual projects.

3. Develop a less adversarial attitude toward change. Much is written about scope creep and change control in project management circles. There may be a tendency to take too hard a line toward change. The reality is that business conditions, needs, and strategy may well change over the lifespan of many projects.

Let’s move our definition of project success away from the old metrics of “on time and within budget” toward more realistic measures of business success. Some more appropriate ways to judge success of a project include:

• Did the project fulfill the objectives, as defined in the original project charter (if you don’t do project charters or business cases, add that to thei list of resolutions) and all subsequent change requests?
• Are end-users satisfied that their requirements have been implemented, and can they easily perform their daily tasks using the new system?
• Some metrics are specific to the type of project, such as:
  • For business intelligence projects: Has this project enabled the business to make better and quicker business decisions by putting better data and drilldown capability into their hands?
  • For projects that install new transactional systems: Have we improved overall efficiency and accuracy of critical business transactions?

4. Develop an efficient framework for project triage. Not every project needs the same level of support. Some projects need to be suspended or rescoped as business needs change. Regular project triage is a best practice that helps organizations make sure they are keeping IT budgets aligned with business needs. Make a commitment to quarterly triage in 2010. Incidentally, if you haven’t taken our project triage survey, we would value your input in this area.

5. Re-order the priorities of your project managers. Make sure that they understand that their most important responsibility is maintaining a healthy working relationship with the business. Tracking status, updating the plan, and managing the tech team are not the key enablers of project success.  The most valuable skills to strengthen in your PM staff  are related to communication, conflict resolution, consensus building, and salesmanship (they will often have to “sell” reluctant stakeholders on compromise solutions).

New Year’s resolutions are really just an attempt to institutionalize a project management best practice that should become standard operating procedure throughout the year: periodically re-examine your approach and commit to continuous improvement efforts. That’s the real secret to successfully building a high-performance project management office within your organization.

Ten Ways to Ensure Project Failure

Sometime ago I read an article about the top ten ways to destroy the earth. Although it is a bit morbid to even think about such a topic let alone compile a top ten list, it certainly is an interesting scientific problem. Blowing planet earth to bits is not as simple as it may seem. It takes considerable amount of energy to blow up six sextillion tons of rock and metal. However, there are some exotic ways to get the job done. From creating a micro black-hole on the surface of the earth to creating an anti-matter bomb with 2.5 trillion tons of anti-matter to creating perfect Von Neumann machines (self-replicating), they are all pretty futuristic and not part of our everyday experience. Some may say- “why even think about such an absurd subject?”, but it does have few practical applications. If nothing else, it helps us think about possible dangers to the only known planet capable of supporting life.

While blowing up earth may for now be out of our grasp and may require giant leaps in technology, blowing up an IT project is quite easy. I can say that with authority, because I have seen many projects self-destruct right in front of my eyes and at times I may have contributed to some of them. So here are the ten ways of blowing up an IT project:

1. The Missing Matter—Requirements: Lack of business and functional requirements or requirements lacking appropriate level of detail.
2. Progress Black Hole: Lack of mechanisms to measure progress, milestones, and deadlines.
3. Caught in the Gravitational Pull of Technology: Focus on technology itself rather than achieving business objectives through technology.
4. Supernova – Out of Resources: Unrealistic expectations and deadlines – trying to achieve too much in too little time and with too few resources.
5. Consumed by Nebulous Clouds: Constantly changing requirements and feature creep. Inability to give the project and product a solid shape and direction. Lack of proper change control process.
6. Bombarded by Asteroids: Loss of focus and progress due to multi-tasking on unnecessary side projects and other distractions.
7. Lost in Space: Lack of a well defined project plan with appropriate level of details, milestones, and resource allocations.
8. Too many WIMPS (Weakly Interacting Massive Particles): Lack of interaction with the business users, lack of sufficient number of check points, lack of business user involvement during the planning, build, and deployment phases.
9. Journey to the Edge of the Universe: Attempting to run a project with bleeding edge technology, inexperienced project team, and poorly understood business objectives.
10. Starless Solar System: Lack of clear and convincing business case and mapping of how the project will help to achieve the business objectives.

Practical Project Management

In times like this every PMP needs a healthy dose of a new and improved PMP, that is, project management practicality. As the recession lingers, those of us who drive the success of projects, programs, and any corporate initiative are going to have to find new ways of doing more with less.  Here are seven practical tips for cutting corners without sacrificing project success.

1. Curtail time-consuming interviews for requirements-gathering. There are several easy ways to cut the effort required to gather information from subject matter experts:

• Group them by functional area (when appropriate) and avoid interviewing single stakeholders.
  
• Use structured information gathering templates and require that they take a pass through them and begin filling in the required information before the meeting. The keyword here is structured. I prefer Excel templates with restricted ranges of responses, rigidly enforced with data validation limiting those responses to list.  STructure the information you need into columns, apply data validation, and put explanatory notes as a cell comment in the column headers.

2. Make your meetings more productive.

• Know your goals. Have an agenda and be ruthless about sticking to it.
• Limit the attendees to those people with decision-making authority
  and real subject matter expertise. Bigger meetings cost more and waste more time.
• Appoint a live note-taker. The note-taker should type the notes live during the meeting and send them out before the end of the day. Transcribing from written notes is wasted effort.

3. Restructure your project team. Combine roles and responsibilities, because fewer roles mean fewer handoffs. It’s better to have a smaller team running above 100% utilization than a larger team at or under 100% utilization.

4. Carefully define the scope of your analysis/requirements gathering effort. Don’t waste time documenting standard business processes in excessive detail; concentrate on the areas that have unique and/or critical requirements.

5. Hold the line on customizations. They add cost to the current project, and will complicate upgrade and migration projects down the road.

6. Request a mini-business case for custom reports. Every custom report should have a place in the spec that describes the business action that the report enables, as well as a list of alternative sources for the requested information if the custom report is not available. This will help the project sponsor make an informed decision when approving the custom report request.

7. Make project status more transparent. To reiterate an earlier post on PMOs: A well-defined, user-friendly, and well-maintained project portal site can cut down on the need for lengthy status meetings. Milestone status, next week’s key tasks, and open action items can be posted to the portal site. A weekly meeting can be used for exception-based reporting on lagging milestones and critical issues, allowing the project sponsor and key stakeholders to participate in resolution during the meeting.

Collaboration Style Revisited

When looking at the results of our last poll on collaboration styles, several things jumped out at us.

1. Nearly a third of the respondents are either still relying on email collaboration or under-utilizing basic portal functionality (document checkout/checkin for version control).

2. Among users of collaboration portals, there was an even split between Sharepoint and other tools.

This led us to wonder how broad corporate adoption of collaboration tools might be. And it leads us, of course, to another poll.

Comments always welcome, and in case you missed the first post in this series, it’s still open and you can vote here.

Missing pieces in your portal implementation plan?

Clearly, many companies have collaboration tools such as portals on their to-do list as one of the top technology trends of 2009. Even this early in the year, we’re already hearing some frustration with the earlier adopters, in terms of the difficulties in getting their organizations to actually embrace the powerful functionality of collaboration portals. 

Here are four key elements to fostering user adoption of collaboration tools. They need to be baked into your portal implementation plan, because you need to sell this change aggressively into your organization to realize the full ROI of the technology investment. Sometimes, this can be the part of the implementation that requires the most finesse.

1. Strong executive sponsorship. Portals can fail when they are perceived as an IT initiative. Someone at the top has to get the early message out about how the portal can make the whole business more efficient. Executives can then lead the way by making the portal the preferred place to interact with the executive team.

2. Data Migration plan. If your business has traditionally used shared drives for file-level collaboration, make sure your portal migration plan includes moving the latest versions of files over to the portal site and decommissioning the old shared drive. 

3. Refine your collaboration processes to fully exploit the new technology. Workflows that have burdensome review/approval cycles can bog down any attempt at collaboration. While such rigor is useful in highly regulated businesses, it’s overkill in many others. If you make the portal a place where people can quickly share lessons learned and the new tools they develop for doing their jobs more efficiently, they will rush to embrace the portal. Limit approval requirements to the bare minimum and don’t let their contributions languish an an approval queue.

4. Change management. More than just training in portal functionality is needed. Key elements of your portal change management plan include organization design (assigning clear responsibility administration and creation/maintenance of portal sites), getting the message out early and often about the benefits of portal functionality, training in key user procedures (checkin/checkout, alerts, discussion boards, etc), and handholding as the business units create their own working sites.

If you’ve implemented a collaboration portal and are finding that your enterprise is ignoring it or under-utilizing its capabilities, please leave a comment–we’d love to hear about the challenges and how you’ve overcome them.