It's a complex project -- a new application with lots of data integration challenges, a web front-end, a new DBMS 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-service SLAs. 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 (feasibility study) phase and then to implement it. The question is, who is IT is good enough to handle it?

Based on past experiences, 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 in the past, teams don't form or don't work well, and IT struggles to deliver large projects like this one.

The PMO as Project Manager

For a project so complex and important, past experiences may suggest that we need a "super project manager." Acting on that believe, many IT organization include within their Project Management Office (PMO) a pool of project management experts who serve as project managers for tough projects.

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 (applications engineering, web engineering, DBMS engineering, server engineering, etc.).

In other words, the PMO is selling (whether or not money changes hands) to clients a product (the application) which is in another group's domain. To put it bluntly, when the going gets tough, 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 like what help they'll need from all those other groups, what 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 the discipline of applications engineering. As such, they're not qualified to make technical decisions.

Sure, PMO staff are 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 these project-related decisions. Are we vesting authority in the people best qualified to weild it?

And is the entrepreneur responsible for running the applications engineering line of business 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 and makes commitments to its customers, delivers its products and services, and supports its installed base. Can an applications development manager really be an empowered entrepreneur when the PMO occasionally takes over and delivers its products?

If you were that applications development managers, might you wonder how you can be sure that the project manager will make decisions that are in the best interests of the applications development line of business in the long term? Wouldn't it be tempting for the PMO project manager to cut corners, get the project out on time, get the credit, and perhaps accept undue risks with regard to future maintainability, supportability, operational effeciencies, integratability, etc.?

Where Did We Go Wrong?

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.

In fact, excellence in teamwork and project management does not require confusing accountabilities and disempowering entrepreneurs. Applications developers sell applications, big and small. 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 knowledge of what skills are needed on the team. Most applications developers know whose help they need, and know exactly what they need to buy from others. The real problem is generally a lack of an organization process to get the needed help from others, or perhaps 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. Rememeber that applications developers are entrusted with smaller projects.

Sure, if you expect one person to manage and control the activities of a large project team, it would take an exceptionally talented person. Consider the challenge of managing one of the most complex projects in the world: getting a cup of coffee.

With the traditional approach, you'd have to tell Juan Valdez how many coffee beans to plant, coordinate shipments of fertilizer, hire the labor to harvest the crop, build a truck to carry the beans to the dock (without even thinking about where the roads came from), plan a ship (fully staffed) to bring the beans to your country, arrange a railroad (fully staffed) to ship the beans to the roasting plant -- natural gas, cans, labels, trucking, filters, water, the mug made in Taiwan -- it all adds up to an unthinkably complex project.

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 Business-Within-a-Business Approach

The market handles the challenges of teamwork and project management perfectly. In the real world, all you need to do is run down to your grocery store and buy the beans and filters. You let the grocery manager procure those products, managing their suppliers and their staff. The distributors they buy from, in turn, manage the manufacturers, shippers, and store staff. And so on, all the way back to Juan Valdez.

In the market approach, you may be the project manager for a cup of coffee, but all you have to do is manage your immediate suppliers. They, in turn, manage their suppliers, etc.

And to make your life easier still, your suppliers don't just provide you with warm bodies. They give you complete subcomponents -- a can of coffee grounds, a mug, a coffee-maker, filters, electricity, and water. You don't have to manage their staff; they do.

In the real world, there's not just one project manager; everybody on the team manages their own sub-projects. 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. Consider the general contractor who sold you a home. He or she hired plumbers, electricians, sheet-rock installers, roofers, etc. And each subcontractor delivered a product -- a component of the house -- not just staff for the general contractor to manage.

The same goes for every product and service you buy. Applying this approach within organizations is equally straightforward. There are only three rules:

First, everybody is the prime contractor (ie, project manager) for products and services within his or her line of business; and nobody sells products or services outside their line of business (not even the PMO).

Second, the first job of a prime contractor is to line up needed subcontractors. This involves working with peers to gain commitments for deliverables, not people.

Third, everybody is accountable for delivering their products and services as promised, whether it's the prime contractor delivering the whole solution to clients or subcontractors delivering their components to the prime. This degree of integrity is based on two more principles: Never make a commitment for others. And never make a commitment you can't keep.

How It All Plays Together

Back to our original example. The client wants to buy an application. Regardless of complexity, it's clear that the prime contractor is the applications development group.

Both at the proposal stage and the implementation stage, the prime contractor subcontracts for all needed components -- other applications groups for data feeds, the web CMS group for the front-end, DBMS engineers for the data model, etc.

And let's not forget one very important subcontractor: In any line of business, a project manager can (and should whenever needed) subcontract to the PMO for project planning services, project management advice, and project data administration. In this way, excellence in the discipline of project management is available to any project in any line of business.

Just remember, to avoid confused accountabilities and disempowerment, the PMO serves a subcontractor, not the prime, helping everyone succeed as project managers in their respective lines of business.