Networking optimize

Setting up priorities in an "A" world


Lack of priority information is the death of management and the bane of leadership. It is also the single most common problem project managers run into when trying to filter activities into a critical path. The sophistry behind "They are all As" doesn't even begin to merit a response. At some point, usually too late, someone will have to decide what people will actually DO with their time. People simply cannot do everything at once no matter how much modern business theory says they should.

When we find ourselves stuck between the rock of responsibility and the hard place of ambuiguity, we need to sort out what is really important for our teams to do. The simplest, and probably least useful, way for us to do this is to pull together a critical path or project plan (or both) based solely on our project's immediate needs. We lay out the tasks in chronological and/or dependency order, organize our resources, and execute. Other considerations become obstacles to be overcome, modifiers to our iron triangle which we will remove in order to optimize our own performance.

The above represents the simplest and most traditional approach to project activity. It also reinforces a simple cognitive fallacy -- the idea that our projects operate in a vacuum, or that our success in one area somehow prevents or alleviates failure in another. By intentionally setting the horizon to close to our own immediate interest, we become vulnerable to both outside interference and the political ramifications of having too few allies. Worse, our projects might start to fail and we will not know why. We end up saying things like "We did everything right, why did they cancel our project?" when the company is about to fold.

Another, more complex approach involves the coordination of basic activities between projects. Say, for example, that our critical path involves the installation of a VPN connection to an outside provider. We could just get the networking group to install our VPN and be done with it. Alternately, we could coordinate with the other project managers who also needed VPNs installed, create a standardized form for VPN information, and arrange with networking to have a "VPN day" when we built a bunch of VPNs. The first approach would get our own work done more quickly. The second would slow our project down a bit but would allow the network department to use their time more effectively, clean up several projects at once, and make sure the resources were on hand in case we needed advanced troubleshooting.

This kind of thinking (grouping and organizing activities among projects) creates what management books like to call "synergy." This is not a real synergy - it's just basic coordination. Real synergy comes about when we leverage the work of one project to enhance the result of another.

For example, imagine we have the resources to deploy three workstations along with the new system we are to install. The site actually needs 12 new workstations to get full value from the new system. We could wring our hands or tell them to buy a bunch of new computers. Alternately, we could coordinate with other project managers who also have resources to install new workstations. If we can coordinate it so that two or three workstations for three or four projects all arrive relatively simultaneously, we meet our client's need without exceeding anyone's budget.

So, if we have three basic approaches to take, which should we choose? When do we bull ahead, when do we coordinate our activities, and when do we seek out synergy which creates a result greater than the sum of its parts? The answer to that gets back, in a meandering way, to our question about setting priorities.

No one may want to prioritize, but we can tell by who receives rewards which of these three approaches receives approbation, additional resources, and raises. In most environments, it's safest to just charge ahead. In a few, the managers encourage project managers to coordinate their activities. In a rare handful the executive team seeks out and rewards true synergy, even when synergy creates a situation where one or more of the individual projects falls behind.

What kind of environment do you work in?

8 comments
Wayne M.
Wayne M.

This article touches on my concern about the PMI definition of project and the related acceptance of Project Manager as a discrete role. PMI defines a project as an temporary endeavor with a defined completion. This makes it almost impossible to prioritize because the two choices available for a project are, do it or don't do it. This is exasperated by having a manager dedicated to a project. This encourages optimizing decisions concerning the project without regard to the program or operations as a whole. Management of individual projects needs to be de-emphasized in favor of managing for long term purposes. Prioritization can only occur when there is a series of planned projects. Treating projects as one shot efforts places an unnecessary obstacle between optimizing operations across parallel efforts.

Absolutely
Absolutely

Overuse of "project managers" encourages micromanagement tendencies in the "project managers" and misplaces economic credit from those who do the work, to those barely competent enough to describe the work at a "high level".

casey
casey

I disagree with the entire premise of this post, while agreeing with the basic conclusion. In no way does the general definition of a project make it impossible to prioritize. Nor does having a dedicated project manager result in organizationally sub-optimized decisions. If you are experiencing either of these conditions you need to examine the culture in which they occur. You're right about treating projects as one-shots, unless that is what they truly are. It is management's responsibility to prioritize and allocate resources as well as setting the tone and expectations for a project's governance and ultimate outcome. If you have weak and myopic management, your projects will take on similar characteristics.

mgordon
mgordon

IMO, a powerful obstacle to any kind of coordination or synergy is "turf building" and disagreements over how to apportion the cost and benefit of joint operations. The "Darwinian" outcome of this is that companies that achieve agility, synergy or as you say ordinary coordination, will fare better than those that do not. A programmer that understands GAAP (Generally Accepted Accounting Principles) will fare better than one who does not, if the project involves automating an accounting package. A company that has need of both marketing and computer repair (can you name one that does not?) will be better served if the PC guy is also a good photographer -- leverage one road trip and get PC maintenance and marketing photographs for half the cost of doing each separately.

apotheon
apotheon

. . . but I tend to agree, in practice, that many project managers end up serving exactly that "purpose". On the other hand, that's not much different from more traditional managers. A good manager is hard to find, regardless of the type of management (s)he's doing.

Absolutely
Absolutely

It's "myopic management" that leads to "treating projects as one-shots" and in turn to the emergence in business vocabulary of the term "project managers" as distinct from simply "managers", who are traditionally responsible for defining tasks/projects according to the needs of the business, delegating work, and [u]deciding how much independence to grant to subordinates[/u] in their work on those tasks/projects. The term "project management" simply means, to me, that the actual manager is reacting instead of managing, and is being paid for the hard work of micromanaging that the "project managers" are actually doing instead of contributing to the work of accomplishing a task. I think a better organizational model is to work as peers from the time a project is delegated to the team to the final editing of the report of the project's completion. "Project managers" just get in the way.

Absolutely
Absolutely

[i]For clarification: "Project management" as a business term is used to discriminate between activities which are operational or on-going in nature and those that have a limited duration. The term in no way releases "managers" from their general responsibilities nor does it foster "micromanaging" (to direct or control in a detailed, often meddlesome manner).[/i] I can only tell you about my experience of "project managers". Yours seems to have been less negative. I'm happy for you.

casey
casey

In your model, who decides whether a project is needed, the required resources (human and capital) and what the final deliverable should be? For clarification: "Project management" as a business term is used to discriminate between activities which are operational or on-going in nature and those that have a limited duration. The term in no way releases "managers" from their general responsibilities nor does it foster "micromanaging" (to direct or control in a detailed, often meddlesome manner).