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.

Whether we're asked to adjust a process, redefine objectives, or restructure a team, the ability to manage changes will serve us better than hard skills in the topic.

I've found Kotter's 8-step change model a good guidance to implement changes. However, I'd like to add two ideas.

Building a case for change can involve both objective and emotional arguments, such as:

• Cost-benefit analysis
• Success stories
• Enable organisation's strategy
• Solve frustrations
• Leverage pride

The ability to make changes also depends on the ability to convince or influence others. In this area, I suggest working at both the group and the individual levels, with appropriate techniques. For example, the people we can convince with a formal presentation are very different from the people we can convince with an informal face-to-face conversation. The message that we want to convey also conditions the technique.

The "techniques" include:

• Formal presentation, larger audience and limited interactions
• Meeting with a few people, open discussion
• Spontaneous face-to-face discussion
• Discussion over lunch or coffee
• Email

It is a good idea to meet with sceptics individually, as it may help to better address their concerns in order to bring them on board. Similarly it's a good idea to include a champion (convinced person) in a meeting with people who are not yet convinced.

Just look back at your own experience to identify a situation when you were able to convince people to buy in your idea. You can guess which techniques were effective. Most of us use these "techniques" unconsciously. Great influencers naturally mix and match the techniques for great results. If you have such a person around you, try learning from him/her – it's the best way to improve this skill. Have also a look at the related topic of stakeholders management.

Have you already had to collaborate with someone who constantly disagrees with you, or with someone who has the uncanny ability to summon a heated argument out of thin air, or maybe with someone who seems bent on undermining your work? With up to 5% of the population deemed as "difficult people", we’re bound to meet them over and over again. Every workplace has its seven dwarves, and not all of them are as funny at the office as they are in a fairy tale. We can’t just ignore or get rid of them therefore we have to manage them.

Note that this issue applies whether you are in management or not. Top-down authority is overrated and will not help much when dealing with difficult people (the only exception being if you are at the very top).

Compared with other people-related issues, coping with difficult people stands out because the problematic behaviour is not associated with a particular topic or situation, but comes from personality. Since there is not a well-defined problem to solve, traditional conflict resolution techniques are of little help. It’s more like a collection of pervasive, grinding, irritating habits that’s inflicted on close colleagues.

Typical problematic behaviours of difficult people include:

• Aggressiveness, arrogance, condescending, judgmental and opinionated attitude.
• Irrationality: even conventional logic doesn’t get through. There simply is not common ground for discussion.
• Nagging: continuous unasked-for remarks about petty details.
• Stubbornness and excessive pride, leading to the inability to accept comments and to collaborate in a team.
• Playing solo, trying to exclude you of everything they do.
• Trying to get involved in everything you do, acting as supervising your work.
• In contradiction with all of the above, constantly emphasizing the importance of professionalism, communication, flexibility and so on (remember the saying "the wise never says he's wise"), therefore rationalizing their behaviour as being for the good of the team/project/organisation.

You might wonder how these people are still around. First, they behave much smoother when they have a larger audience. Their behaviour is not obvious to casual observation. Second, and perhaps more importantly, their behaviour often borders on professional misconduct but never quite gets there. There is always enough ambiguity in order for an observer to give them the benefit of the doubt. Moreover, their behaviour tends to affect only things that do not leave records, such as discussions and everyday collaboration.

What motivates difficult people? To win. And in order for them to win, people around them have to lose. Whether the stakes are high or the topic is mundane, difficult people are obsessed at being right and proving others wrong.

Next: A manager's perspective

Pages: 1 · 2 · 3

Let's keep in mind that it is much easier to convince managers with a PowerPoint than it is to convince teams with implementation details.

I'm suspicious of consultants who present recommendations and leave the implementation to others.

IT governance is about the stewardship of IT resources on behalf of the stakeholders who expect a return from their investment. It comes from the need that "corporate managers should be working on behalf of shareholders to allocate business resources to their optimum use (Alan Greenspan)."

Governance drives the need for compliance. The compliance requirements can be either internal or external to the organization. Internal compliance requirements refer to a set of rules that the organization defined for itself based on the belief that it will reduce risks and increase performance. For example, an organization could decide that it has to comply with CMMI level 3, in which case it will set this standard as an internal compliance requirement. On the other hand, external compliance requirements are usually imposed by external bodies such as governments. For example, a government can mandate organizations to comply with a set of rules such as Sarbanes-Oxley (SOX).

Ultimately, governance is a top-down approach driven by financial results and reporting. It is supposed to have financial impact and is defined at the corporate level and implemented throughout the lower levels. SOX is an excellent example. The goal of SOX is to ensure the accuracy of financial reports. We might wonder what's the relationship between SOX and IT governance? Given the critical role that IT plays in organizations, it is not difficult to imagine (see Wikipedia: IT controls and the Sarbanes-Oxley Act).

To comply with Sarbanes-Oxley, organizations must understand how the financial reporting process works and must be able to identify the areas where technology plays a critical part. In considering which controls to include in the program, organizations should recognize that IT controls can have a direct or indirect impact on the financial reporting process. For instance, IT application controls that ensure completeness of transactions can be directly related to financial assertions. [...] Application controls are generally aligned with a business process that gives rise to financial reports.
- Wikipedia, Information technology controls

We can ask ourselves how can an organization adopt a structured approach to implement controls in order to comply with regulations such as SOX? To do so, it can rely on popular IT governance frameworks, models, standards, or collections of best practices such as:

• IT Infrastructure Library (ITIL) focuses on services management.
• Control OBjectives for Information and related Technology (COBIT) provides a set of generally accepted information technology control objectives for day-to-day use by business managers and auditors.
• ISO 27001 and ISO 27002 essentially focus on the IT security. ISO 27002 and COBIT complement each other.
• CMMI is a model for process improvements. CMMI-DEV specifically addresses product and service development processes.

However, these IT governance frameworks only describe what should be done to address IT governance needs, in the forms of criteria, objectives, levels, and so on that express compliance requirements. Therefore, organizations have to translate these requirements in practices for their specific context. Real-world implementation includes business processes, technologies, information systems, and so on. One way to help implement the required controls is to rely on product and service development governance methods (also called project governance). The two most popular product and service development methods are Project Management Body of Knowledge (PMBOK) and Projects in Controlled Environments (PRINCE2). PMBOK and Prince2 are widely regarded as standard project management methods, PRINCE2 being used mostly in Western Europe and PMBOK predominantly in North-America.