CIOs who can deliver projects on time, on budget and as advertised are valued members of any enterprise executive team. Here are some of the key elements to successful project delivery.
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?
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 is the prime contractor (i.e., the 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 number one 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
Now 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- to other applications groups for data feeds, to the Web content management system group for the front-end, database management system engineers for the data model and so forth.
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 as a subcontractor, not the prime, helping everyone succeed as project managers in their respective lines of business.
By getting the processes right, an IT organization can have excellence in teamwork and project management without the need for disempowering super-project managers. Market-based processes that identify a prime and subcontractors, combined with the practice of subcontracting for deliverables rather than just people, make large-scale project management within everybody's capabilities.
You can read another version of this article on consultant N. Dean Meyer's website with links to other Beneath the Buzz columns, relevant white papers, books and other resources. Contact him at dean@ndma.com.