The Multi-Dimensional Project Mosaic
By definition a project delivers a well-defined product, but as a thing itself it’s not so concrete. There are dimensions, perspectives and vectors: pilot projects, sub-projects and programs; and being an abstract thing that exists in the minds of the stakeholders, even when we think we’re talking about one project, there is never just one project. If you’re working on a project, I guarantee you’re working on many.
Five years ago the Project Management Institute introduced the Program Management Professional credential, PgMP, acknowledging that there are wheels within wheels and some projects formally comprise multiple projects, the collective management of which requires specialized skills. When each project is supporting one ultimate end, the lines between the component projects can become fuzzy. In my days with the Canadian air force the biggest program at headquarters was the CF-18 procurement. Once you have an airframe, fighter jets need a project to arm them, a project to establish training systems, one to develop maintenance infrastructure and procedures, others to establish tactics, communications protocols, and many more. Most of these were programs unto themselves: training systems need classrooms and materials covering the Canadian version of the aircraft; full motion simulators save costly flight time; and so on. It was a task of monumental complexity to sew all of these mutually interdependent projects together such that someone would be able to tell the Chief of Defence Staff with certainty what the CFB Cold Lake flight line would look like on some future date (and today there wheel turns anew as offices are staffed for the CF-18 replacement program).
Managing all the resources and dependencies within a program can be mind-bending enough, but there are subtler ways in which projects (or perceptions of projects) combine that need to be grasped. Consider an example in which Company X wishes to buy from Vendor A a system through which X can sell their product online. Eager Vendor A tells Company X that they have assigned Mary for the engagement, and the CIO of X says that’s great, Mohammed will be her point of contact. The CIO of X thinks Mohammed is his Project Manager. But Vendor A is thinking of Mary as the PM. It’s not uncommon in these arrangements for both to actually be referred to as the project’s PM. Usually the distinction makes no practical difference, or when it does there is enough context to keep things from being confused. But the problem is not one of a clash of titles. The titles are in fact both accurate, because both PMs are leading a different project. Mary’s project is to develop and customize software that meets the expressed requirements of their customer, test it, deliver it and obtain the client’s acceptance. Mohammed’s project is to get some vendor-supplied software, deploy it on his company’s servers, populate it with the catalog data and make it available to customers.
Now imagine that this new roll-out is going to an established network of buyers that are used to dealing with Company X in a much less automated fashion. The company’s CMO then has a project and tells Manisha to manage it. Manisha’s project may involve providing training and demos, distributing new marketing materials, coordinating the issuance of IDs and passwords, and so on. All of these complex undertakings require a project manager, but they’re very different projects, for all that they are complimentary and everyone involved is pulling in the same direction.
It seems like a very simple and obvious thing when I write it out like this. Human beings usually adjust their perspectives intuitively. If upon receiving his assignment, Mohammed calls up the vendor and says “Hi, I’m Mohammed, I’ll be the PM for our new project” he is unlikely to be confused if he hears “Great, let me get Mary on the line, she’s the PM we’re assigning.” But it pays to understand these distinctions consciously. A vendor I work with now has a customer-facing PM who abruptly disappeared to deal with a family tragedy. The president of her company wasn’t used to thinking of projects in the this variegated manner and without “his” PM he didn’t know who to communicate with. While the crisis lasted he caused a great deal of confusion by calling the product owner, the CIO, team members, whoever he thought might help in a given instance – everyone but the customer’s project manager. In another example, I was once assigned to a vendor-furnished software project by my boss who wasn’t satisfied with how the project had been going along with only a contractor as our point of contact with the supplier. The first meeting was a disaster, because the contractor had understood himself to be the company’s PM, not the vendor’s PM, so couldn’t understand why I was taking over the agenda. Failing to see all of the projects at play can lead to friction and misunderstanding that undermines the project you think you’re working on.
Any project that’s visible outside of one company or even one department comprises many projects. There are often some that feed one ultimate delivery by providing different components or support elements; but there are always the different projects that exist in each team member’s mind, each different facets of the same collective undertaking to deliver one ultimate product. Understanding explicitly how people perceive this kaleidoscopic property of projects can avoid a lot of spinning wheels.
« Cybercreeps and Cybercrats (Part 2) Staying Out of the Project Bermuda Triangle »
