• White Papers |
• Bloggers |
• Video |
• Webcasts |
• Events |
• Solution Centers |
• Newsletters |
• Magazine |
• RSS

The Secret to Successful Project Teams

It doesn't take a project management guru to manage complex projects. Instead, give responsibility to the people who know best how to do the work.

By N. Dean Meyer

March 05, 2008 — CIO — Your IT department is taking on a complex project—a new application with lots of data integration challenges, a Web front-end, a new database-management system platform, dedicated servers in the data center, and field-office training during the roll-out, along with all the usual issues of change control, help-desk set-up and contracting for ongoing support-services. It looks like half the managers in IT are going to be involved, one way or another.

This project needs world-class teamwork and project management, both in the proposal or feasibility study phase and the implementation phase. But based on past experience, applications developers don't seem to be up to the challenge. Sure, they're great engineers and can do their own parochial share of the project. But they don't seem able to pull all the pieces together and manage the entire project. Too often at your company, teams haven't formed or haven't worked well, and IT struggles to deliver large projects like this one.

Should Your Project Manager Come From the PMO?

Your instinct might be to appoint a "super project manager" from your project management office (PMO). Many IT organizations include within their PMOs a pool of project management experts who serve as project managers for tough projects such as this one.

Language is very important here. The term "project manager" means the individual who's accountable for delivery of the project — in this case, the delivery of a new application. Translating this into the language of business, the client "buys" an application from the PMO, which in turn gets help from various other managers (such as applications engineering, Web engineering, database management system engineering, and server engineering).

In other words, the PMO is selling to clients (whether or not money changes hands) a product (the application) that is in another group's domain. In other words, when projects are difficult, the PMO takes over delivery of other managers' lines of business.

This approach leads to a lack of clear accountability — the opposite of good project management practices. Who is really responsible for the end-to-end delivery of applications? Is it normally the applications group, but sometimes the PMO? How do clients know where to go for what, and whom to hold accountable for results?

If the PMO really is the project manager (accountable for delivery of the whole thing), is its staff qualified to make decisions such as what help they'll need from all those other groups, which development methods and tools to use and key design decisions throughout the project?

 

Email

Print

Comments

Share [+]

Digg This

SlashDot

LinkedIn