Moving from Functional to Project Structure

Moving from Functional to Project Structure
By Bruno Collet

Many organizations face the challenge of moving from a situation where they produce a limited number of standardized products, to a situation where they have to constantly tailor their products and innovate in order to remain competitive. These two situations require very different organizational structures. The first one is better served by a functional structure, whereas the second one is made easier by a project structure (or a matrix structure with a strong project component).

As a whole, a functional organization is best suited as a producer of standardized goods and services at large volume and low cost. Coordination and specialization of tasks are centralized in a functional structure, which makes producing a limited amount of products or services efficient and predictable. – Wikipedia

In a project organization, team members are often co-located, most of the organization’s resources are involved in project work, and project managers have a great deal of independence and authority. – PMBOK 4th edition

Analyzing the situation and writing a nice diagram of the new structure represents no more than 1% of the work. The 99% remaining consists in convincing people and in making it happen. It’s interesting to have a look at how different stakeholders might be involved or affected by such a transition.

• Top management has to champion the transition. It is not an issue because executives and high-level managers will benefit from the change while their power will remain essentially unaffected (they are located “above” the change of structure).

• Workers tend to adopt the change without too much trouble because they usually benefit from it. Indeed, when functional silos generate inefficiencies in projects, the project gets delayed and ultimately the team is subject to more pressure and frustration.

• The problem usually comes from mid-level functional managers, who perceive the change as a huge loss of their power. Instead of having project managers reporting to them, they will have to support project managers by providing the required resources. Actually, it is not so much a loss of power than a refocusing on what functional managers do best: manage a pool of specialized talent and other resources.

• Although project managers gain power and therefore tend to embrace the transition toward a project organization, some issues can surface. For example, in a functional structure many project managers do little more than coordination (no insult intended). They might have to be trained and coached in order to properly manage other aspects of projects, such as acquiring and developing the team, really managing budget, scope, schedule, quality, and so on. Whereas project coordination is essentially a support function for the project team, project managers have to lead the team, which requires very different aptitudes.

Moving from functional to project structure also calls for fundamentally redefining what a project is and the related processes. A project typically spans several functional areas. However, in a functional structure, each so-called project usually spawns one relatively independent project for each functional area involved, with a separate project manager. For example, the software development department will have a project manager to take care of its very own software development project, the QA department will do the same for QA, and similarly for marketing, IT infrastructure and so on. The scope of the project that should normally span multiple functional areas, along with its budget and other aspects, will similarly be chopped down in narrow functional slices (making project-wide coordination a communication hell). The project management process has to be adjusted in order to take the new organizational structure into account.

In an organization producing software solutions, the driving force behind the transition from functional to project structure is usually the software development unit. Indeed, although in truth the success of a project depends on all stakeholders and not just on the development team, the latter is widely regarded as responsible for the project’s success or failure. In other words, the development team will often carry the burden of inefficiencies caused by an organization structured in functional silos.

As we can see, structure, processes, and culture are intermingled. Change one, and you have to adapt the others.

Bruno Collet combines business acumen with technology know-how. His successful track record comprises Daimler-Chrysler, Siemens, and Loto-Quebec, with roles such as management consultant, project manager, SAP consultant, and software architect. Bruno Collet’s skills are firmly grounded in academic excellence by achieving an MBA at John Molson School of Business and a Master of Computer Science. He maintains a professional website: brunocollet.com.