Wednesday, May 18, 2011

Who defines project goals: top management or implementers?

It matters. When top management defines a project they usually do so because they have information front-line employees don't have: a competitor's new market strategy will affect sales; a new technology will soon be available that may reduce costs; the cost of capital is going up/down which influences the ability to expand.

All good reasons. The risks of a top-defined project: top level managers often don't know enough about implementer constraints and resources: current employee skills do not match the project requirements; current technology can't support project needs; other projects and daily tasks are more critical or salient to the employees' success. Sometimes current employee evaluation, compensation and promotion systems lead employees to focus on goals that are at cross-purposes to the project goals. While this is something within top management control, they rarely acknowledge or even notice it, and therefore it goes unchanged.

When front line employees define project goals, they may do so because they see the need first hand: customer behavior changes, calling for a new service method; access to a supply changes, requiring substitutions; or there's a shift in the labor pool, requiring new training systems.

Again, good reasons. The risks of bottom-up defined project scope are that folks at the front don't have access to or understanding of corporate resources, and may ask for unreasonable funding or management attention. They don't see where the overall organization is headed, and may not realize that their project goals run counter to the strategic direction. And they don't have access to competitive analysis that might require them to speed up or slow down or drop their project.

Ultimately, when project requirements come from the top, the implementers complain that management is being unreasonable: "we can't possibly get this done in that amount of time!" When project requirements come from the bottom, senior managers don't value the outcome and therefore don't reward success and may not supply needed resources or champion-support.

Solution? Communication!

While ideas for projects should come from everywhere, project scope and resource allocation must be defined by a cross-level group. Senior people in the group must recognize that by their very title they may inhibit surfacing of critical information and must therefore make extra effort to create psychological safety within the group. Everyone should recognize what each member brings to the table.

With open communication and clear understanding of each person's limited vision, project goals will be defined more precisely, leading to greater success.


  1. Hi Illysa

    Communication is definitely needed on projects, however the main driver for project goals should be coming from the customer (end user) and the sponsor (whoever is paying for the work). The implementer might determine that requirements are unrealistic and push back, management might support the customer's view, hence as you stated communication comes into play. Specifically technical facilitation, a process I have used on many complex projects which involve many stakeholders (a couple dozen implementation teams) and half a dozen or so business process groups, on top of that you might have a couple of sponsors, and each one of these groups has there own interests and priorities. The communication challenge can get very complicated and tedious hence the need for a facilitator who can assist in reaching an optimum solution, which serves everyone's needs. Engineers focus on optimum solutions, not perfect ones, hence systems engineers are usually the most suited to play this role on a project. I would be interested in knowing if you or any of your readers have come across systems engineers who play this role in non-technology or non-engineering environments?

  2. Interesting Ayman -- you are right: many projects should come from the customer.

    I haven't heard about non-technical organizations using the systems approach. Other readers?