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 centre, 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?
Remember, PMO staff may be project management gurus, but they’re not experts in applications engineering. Thus, they’re not qualified to make technical decisions.
Sure, PMO staff is quick to point out that they get input from others. But the project manager is accountable for delivery of the project, so the project manager has to have the ultimate authority to make project-related decisions. This is not vesting authority with the people best qualified to wield it.
Furthermore, the manager responsible for running applications engineering isn’t really in control of his or her line of business. An entrepreneur owns a business, plans its future, establishes its products, optimizes its methods and practices, maintains its skills, manages its resources, quotes its prices, makes commitments to its customers, delivers its products and services and supports its installed base. The applications development manager cannot really be an empowered entrepreneur when the PMO occasionally takes over and delivers its products.
If you were that applications development manager, might you wonder how you can be sure the project manager will make decisions that are in the best interests of applications development business in the long term? Wouldn’t it be tempting for the PMO project manager to cut corners, get the project done on time and get the credit? And perhaps he or she would accept undue risks with regard to issues like future maintainability, supportability, operational efficiencies and integration.
Clearly project management gurus are critically important on large, complex projects. But making PMO staff the accountable “project manager” raises as many questions as it settles.
Look to the Market for a Better Approach
In fact, excellence in teamwork and project management requires neither confusing accountabilities nor disempowered entrepreneurs. Applications developers sell applications, big and small. In our current example, they are the right choice for project manager, indeed the only choice in an empowered, entrepreneurial culture.
“But,” you ask, “in the past, they’ve struggled with big, complex projects; how can we address that problem?” Consider the root cause. Most problems in teamwork aren’t due to a lack of understanding about what skills are needed on the team. Most applications developers know whose help they need to execute their project, and know exactly what services and subcomponents they need to buy from others. In most cases, the real problem is the lack of a process within the organization for getting that help. The difficulties may also stem from a lack of the discipline required to be confident that others will deliver their pieces of the project reliably without lots of oversight.
Similarly, most problems in project management are not due to a lack of skill in managing projects. Remember that applications developers are entrusted with smaller projects all the time. The mistake is to expect one person to manage and control the activities of a large project team.
Consider the challenge of managing a very complex project, like building a car. This is a project that involves thousands, maybe tens of thousands, of people.
If you had to depend on one person to manage every aspect of such a complex project, you’d be in jeopardy. But fortunately, there is another way.
The car assembly plant “buys” completed engines from another plant that does nothing but build engines. It buys tires from another company altogether, one specializing in that field. Hundreds of suppliers and other divisions within the same company supply parts and assembled subcomponents.
And the neat thing is, each supplier is a project manager for its subcomponent. The engine plant machines the block and buys the spark plugs. The tire manufacturer worries about procuring the rubber and steel belts.
Thus, the final project manager — in this case, the car assembly plant — only needs to worry about managing its next tier of suppliers, and it leaves to them the project management of their piece of the whole.
Breaking project management down into chunks eliminates the need for those scarce super-project managers who can control what every individual throughout this long supply chain does every hour of the day.
The market works in any industry. Applying this approach within IT organizations is equally straightforward. There are only three rules: First, everybody i
