CHAPTER 1

Project Management

1.1 Introduction

Project manager is a role. People within projects may have different roles, for instance a particular person can have the project manager role as well as the lead architect role.

This principle is rather important especially when human resource and/or financial planning needs to be performed. For instance, the hourly rate of a project manager might be different compared to that of a lead architect. You can also monitor more easily the hours spent by the different roles which could have different budgets.

Management also means delegating and monitoring what’s going on rather than performing as much tasks as possible yourself. Delegation, however, means that you are still responsible! When the person to whom you delegated a task and problems arise, you are in trouble as well.

1.2 Why Holistic Project Management?

In Greek, the word “holos” stands for the idea that the properties of a system (physical, technical, biological, etc.) are more than the sum of its parts.

More and more people are becoming aware that we are part of something much bigger and that everything is connected.

Now let’s make the step to project management.

A project has an impact on its environment, which also consists of people in this context. People are directly affected by the project. This could be in a number of perspectives. They might need to change the way they are working for many years, which will cause resistance. Pushing these changes onto these people is neither respectful nor will result in a positive result. People will, rather often consciously, be trying to jeopardize the project.

Imagine . . . how would you react in this situation?

So as project manager you should have a broad and holistic view as well, especially regarding people.

During my psychosynthesis education, one of the often repeated remarks was: “listen to your body.” It took some time to make that step and become aware of what my body was trying to tell me. We human beings have a body, mind, and emotions. We have a thought (mind) that generates an emotion which is expressed by our body.

I’ve seen courses about body and mind language in the Netherlands, by Jos Dolstra, and I have read the book Coaching with Body & Mind Language, which made me even more aware that we need to listen to our body.

Our living attitude reflects the way we have been living. In body and mind language, our body memory is activated. A combination of body language (attitude, movement) and spoken language is used. What shows the body? What is being said and expressed? Which deeper reasons have been hidden?

How many people have stiff shoulders (in fact the whole area between neck, the neck itself, and the shoulders and the upper part of our back)? What do we carry? Worries? Why are we worrying? How are we looking at our reality? Do we fight our reality or do we accept our reality (even though that reality is not what we want)? What do we normally do (take a painkiller)? Do we have the nerves to go into confrontation with ourselves? Are we afraid of being “rejected” by our manager?

1.3 Why Project Management?

Searching the Internet for information regarding project failures (let’s learn from the past), you can find tons of information and causes. The Standish Group is a company performing many research programs regarding project management.

Projects are rather often in the news, especially when they are out of control not only due to finishing must later than planned but also due to budget overruns.

The Standish Group has done a lot of research on this [1].

The majority, about 30%, of the ICT projects has a cost overrun between 50% and 100%. The average across all kinds of companies is around 180% regarding cost overruns.

Regarding time overruns, about 35% of the ICT projects deliver with a delay between 100% and 200%. The average across all kinds of companies is around 220% regarding time overruns.

The next question is: What is being delivered compared to what has been agreed (value for money)? The majority, about 40%, of the ICT projects did deliver what had been agreed between 75% and 100%. The average across all kinds of companies is around 60% regarding what should have been delivered.

In the Netherlands, projects for the Dutch government are terminated after 17 years while there is still no clarity when the project will be finished and how much more the project will cost (which is already tens of millions over budget).

In other words . . . “room for improvement!”

What are the main reasons for project failures (top five covering approximately 55%)?

1. Requirements are incomplete (ambiguous, vague, etc.).
2. Users are not involved (the people for whom the outcomes are intended).
3. Lack of resources (right people at the right time, financials, dependencies [e.g., hardware is not available], etc.).
4. Expectations are not realistic (lack of “expectation management” which will also be discussed in this book).
5. Lack of executive management support (including the project sponsor of course).

1.4 The Project Manager

The project manager is ideally the sheep with five legs . . . (as you can see I didn’t find one and if there would be one it would be a genetic defect).

The project manager is quite often considered to be “all mighty” (also based on my own experience). A project manager is “only” a human being with limitations like anyone else. A project should also “fit” to the project manager. Executive management should be cautious during project assignments. This is also in their own interest. The remark “only you can do this” is pure manipulation and might land you in big trouble. I turned one deeply troubled project into a success (4th project manager). On another project, I couldn’t make it a success.

It is in your own interest to be assertive as well. Get a good picture of the project, and possible history, before making a decision.

What kinds of skills are pretty handy for a project manager? Let me list a number of the most important skills.

1. Be able to work with and build bridges between any type of person both in easy and difficult circumstances (especially pressure when the going gets tough). Networking is key as project manager. Think about dealing with executive management, business management, technical specialists, etc., with different objectives, interests, and agendas as well.
2. Patience, flexible, and creative. Things are not going the way you have planned. Murphy is also one of your team members (and the one you have no control over).
3. Technical expertise. You should know what the project is about. Not the complete detail, but this makes it much easier for you to understand what is going on and to perform, for example, risk management.
4. Planning. The planning is the base for project execution and will definitely be different than the reality. Be happy, otherwise you would lose a lot of fun in your work.
5. Administration and preciseness. You need to have your project properly administered. In case you get ill other project managers can take over with not too much trouble. You should be able to produce the project status, financials, risks, changes, etc., more or less on the spot. Show executive management that you are in control. This will save you a lot of hassle and time.
6. Leadership. I consider the project manager part of the team. You stand by your people.

   If they have to work overtime, you will be there as well and support them where you can (e.g., arranging facilities).

   As you can see . . . not only children can use Duplo (Lego) to express themselves . . .

   

7. Pragmatic and practical. The biggest challenge is to find a balance: sticking to processes and procedures versus getting the job done. Always ask yourself what the real objective is. Beware of satisfying processes and procedures instead of applying/using what is needed. Processes and procedures are intended to help people.
8. High perseverance and high energy. Project management is normally not a 9 to 5 job. This also has an impact on your personal life and for instance your family. When you are working overtime frequently due to project issues this will also have an impact on your family/relation. The pressure might also increase at home at the same time. Be aware of this and discuss at home as well to create understanding (and hopefully get support as well).
9. Negotiation. Try to create a win–win situation. Think both short term and long term.
10. Empathy. This is one of the most difficult and important ones. You are dealing with people, not with things. The chapter about psychology is diving into this subject.

1.5 My View

I would like to share my personal view on (project) management in this section. I see the modern (project) manager as an “enabler” and spider in the web: the person who creates the conditions to enable the team members to perform the assigned tasks; the person who stands by his team; the person who supports his team especially during tough circumstances.

According to me every person should perform self-reflection frequently. This is an important part of personal development! At a certain stage during your personal development, you are able to step one level up (meta level) and observe yourself. What do I think? What do I feel? What is going on in my body? Observe and don’t judge. Look at yourself as though you are always learning and not shooting yourself in case something went wrong. When you consider these as gifts, these lessons learned will make your life much more cheerful.

I do see the project manager as a spider in a dynamic web . . . and a juggler as well trying to keep all the balls in the air.

1.6 The Team Climate

The team climate has a large impact on the success of the project! You should monitor closely the climate all the time!

Keep an eye on how the team members are dealing with each other. Are they committed and involved? Can you hear laughing (not all the time but frequently)? Are they prepared to run the extra mile without too much trouble (i.e., overtime)? If people are ill how long is this on average and are the same people ill frequently? Are people dealing with each other with respect?

1.7 Project Management Methods and Tools

In the global marketplace, a number of project management methods are available. I mention a few here:

1. Prince2. This abbreviation stands for projects in a controlled environment. PRINCE [2] was established in 1989 by the CCTA (Central Computer and Telecommunications Agency), since renamed the OGC (the Office of Government Commerce). In June 2010, the OGC Best Practice Management functions moved into the Cabinet Office.

   PRINCE was originally based on PROMPT, a project management method created by Simpact Systems Ltd in 1975, and adopted by CCTA in 1979 as the standard to be used for all government information system projects.

   When PRINCE was launched in 1989, it effectively superseded PROMPT within government projects. PRINCE remains in the public domain and copyright is retained by the Crown.

   Prince2 is available in both waterfall and Agile.

2. PMBoK. This abbreviation stands for Project Management Book of Knowledge and has been developed by the American Project Management Institute (PMI [3]).

1.7.1 Methods

In the past only the waterfall model was used. The waterfall model is a sequential (noniterative) design process where progress can be seen as flowing steadily downward (like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, production/implementation, and maintenance.

It should be noted that noniterative is not completely true; during project execution it turns out for instance that a change causes requirements to change, design to change, etc., and then these steps are iterative but the main stream of the project is noniterative.

However, the time to market has changed dramatically and also the dynamics. Our world is changing quickly, which requires quick results as well. New methods/philosophies/approaches such as Agile, Scrum, and Lean are concrete examples to adapt quickly in our fast-changing world.

Agile Project Management [4] supplies flexibility and at the same time a controlled process.

In “traditional projects,” the project manager makes the planning and assigns tasks to the team members.

In agile type of projects, the project manager creates the high-level plan. The next step is that the project is continued by iterative steps to create deliverables. The activities to be performed during these steps are determined by the team and not the project manager. The team collaborates closely with the client.

Scrum [5] is an iterative, incremental framework for projects and product or application development. It structures development in cycles of work called sprints. These iterations are around 4–6 weeks, and take place one after the other without any pause. The sprints end on a specific date whether the work has been completed or not, and are never extended (timeboxed).

In Scrum, the following roles are applicable: Product owner (could also be the client), team, and ScrumMaster. As you can see, there is no project manager . . . The product owner defines the product requirements, converting these into a prioritized list, decides the priorities, and takes care of continually reprioritizing and refining the list.

Why not a project manager? Well, in fact, this is not needed while the traditional responsibilities of a project manager have been spread over the three Scrum roles. A project manager could take the role of ScrumMaster, but it should be noted that this is a different role which requires additional training.

Lean [6] is a business strategy and a way of working that focuses on creating value for the client in all processes within a company. The intention is to eliminate waste. This improves the quality, reduces duration times and costs.

The concept was developed by Toyota and is the “Toyota way,” which is based on the 4 p’s: philosophy, process, people (and partners), and problem-solving.

It is strongly advised to use a nonproprietary method in order to prevent dependency on a single company. Some risks you could be running using a proprietary method:

1. What happens if the supplier is bought by another company or, even worse, goes bankrupt?
2. How well are they following the trends to enable you to work with up-to-date methodology matching your current needs?
3. Training might be more extensive and expensive.
4. A proprietary method also requires a proprietary toolset. This requires large investments by the supplier, Who may choose to use a set of nonintegrated tools that make the use less efficient.

1.7.2 Tools

Regarding project management tools there are a large amount available in the global commercial marketplace. The majority of the tools are cloud based, which implies that you don’t have to install software on your computer. All you need is a browser.

These tools normally offer an integrated environment, not a set of (independent) tools, and use a dashboard in order to enable users to drill down into detail from a kind of helicopter point of view.

An approach regarding tool selection could be:

1. Determine tooling requirements (functional and nonfunctional).
2. Make an inventory of available tools and compare the offered functionality with the requirements.
3. Install tool(s) for pilot (noncloud-based solution).
4. Perform pilot and make a final choice.
5. Install/configure tooling in production environment (noncloud-based solution).
6. Educate staff (according to, for instance, “train the trainer” principle).
7. Adapt processes and procedures.
8. Deploy tooling completely.

1.7.3 Costs

Looking at the costs of implementing and maintaining tools within an organization you could look at the following:

For a cloud solution:

1. Software licenses (operating system, application software, etc.)
2. Education
3. Support (software)
4. Long-term storage

For an in-house solution (on own infrastructure):

1. Physical hardware (one-time cost)
2. Software licenses (operating system, application software, etc.)
3. Hardware maintenance (server, network, etc.)
4. Software maintenance (system software and application software)
5. Backups
6. Education
7. Support (hardware and software)
8. Long-term storage

1.8 Project Management Office

A project management office (PMO) is a group/department within the organization that defines and maintains standards for project management within the organization. The PMO strives to standardize and introduce economies of repetition in the execution of projects. The PMO is the source of documentation, guidance, and metrics on the practice of project management and execution.

Standardization

The PMO is the right hand of the project manager.

Portfolio, programme, and project offices (P3O^® [7]) is a best management practice and is aligned to, for example, PRINCE2 and combines a set of principles, processes, and techniques to facilitate effective portfolio, program, and project management.

When the organization is executing more than one project at the same time or the organization is a project organization, a shared project office saves time and costs and makes it easy for project managers to have jump starts as well.

1.9 Project Management Preparation

1.9.1 Lessons Learned

Before starting a project, it is wise to look at the past: lessons learned! Contact project managers and team members of previous similar projects to prevent stepping into the same pitfalls.

Start your own lessons learned document as well at the very beginning of the project. You could consider the following subjects to document (you can use for instance a spreadsheet, database, or text document):

1. Lesson identification (e.g., date and sequence number because you might have more than one per day)
2. Lesson detail (e.g., event, impact, cause/trigger, recommendations, and was it a risk before)
3. Log date
4. Name of person who logged it
5. Priority

You can also log personal remarks such as notes during face-to-face meetings with team members. However, you need to pay extra attention to security and privacy in this case.

Select a tool for documenting the lessons learned, which offers search functionality as well.

1.9.2 Project File

The project file is the conscience of the project! This needs to be in perfect condition and up-to-date (also after the project has been closed).

In case project management tool is used the project file is integrated in this environment.

To keep in mind:

1. Project files need to be stored long term (years). In case problems arise, for example, one year after the project has been finished, such as a claim by the client, the delivery organization needs the historic project data. Quite often by law a retention period of 7 years is required.
2. Take care of access to the project file after the project has been closed. The project staff should have no access anymore (and nobody is allowed to change data after project closure) but access to a support organization must be granted (such as the PMO based on roles and not on persons).
3. Store also signed contracts and other physical papers by means of scanning these documents.

1.9.3 Meetings

The following items are discussed in meetings:

1. Minutes of meeting (MoM)
2. Meeting efficiency
3. Meeting ethics

The minutes of meeting (MoM) are more important than some project managers realize. MoM are for instance quality records. MoM need to be approved by the participants. Approved MoM can save you a lot of trouble as project manager when things are not running smoothly. Decisions taken should be documented in the MoM.

In order to prevent issues, it is important to produce the MoM as soon as possible after the meeting (what I normally do is within 24 hours).

The following items could be present in the MoM:

1. Start with a header which is visible on each page. This header contains, for example, the company or project logo, project name, and the type of meeting.
2. In the footer, the file name and a page number should be present. The file name is composed of, for example, project name, type of meeting, and date (project x Steering Committee 20170419 [the date in this format automatically sorts files in the right order]).
3. List of participants (names, roles, and optional company names).
4. List of people absent (names, roles, and optional company names).
5. Meeting date.
6. Agenda.
7. Meeting objective(s).
8. Action items. Each action item should have:
   1. An identification number (e.g., year, week, and sequence number)
   2. Description of the action item
   3. Person responsible (that can only be one person)
   4. Due date
9. Any other business.
10. Date of the next meeting.

Meeting efficiency

Running a meeting efficiently and effectively is quite often a challenge. First of all people rather often come in late. Secondly, many people are not prepared for the meeting by reading the minutes and having an actual update of action items which have been assigned to them.

Here are some practical tips:

1. Always have an agenda.
2. Communicate the agenda before the meeting (preferably the day before, which also reminds people that there is a meeting).
3. The meeting objective(s) must be clear.
4. Plan meetings at a fixed day and time. This is easy to add to the digital agenda and gives people structure.
5. Communicate meeting ethics (please refer to below).
6. Take care that everyone is having sufficient time to share.
7. Be aware of people drifting away from the item being discussed.
8. In case you are using teleconferencing (e.g., Skype) test the initial time with all participants if this is working properly. Within companies publicly available teleconferencing tools may not be used due to, for example, security or network load.
9. If people are located in different time zones try to find a convenient time for all participants. If this is not possible, for instance, between the United States and India, organize one meeting that is convenient for one time zone and another meeting for the other time zone(s).
10. Run a meeting no more than 1 hour. First of all keep in mind that people have more things to do than your meeting. Secondly attention automatically drops after one hour.

Meeting ethics

Meeting ethics are intended to communicate and agree with each other how to deal with each other during meetings (e.g., team meetings). Communicate these ethics during the kick-off meeting and ask for commitment.

Examples of meeting ethics (have a one-page document to share):

1. Be on time for the meeting.
2. Be prepared for the meeting (minutes have been read, feedback ready, status of action items assigned to you, items for “Any Other Business,” etc.).
3. Listen to each other with respect. Don’t interrupt other people.
4. No processing of your e-mail or smartphone use during the meeting. Your attention should be with the meeting.
5. Have a positive attitude and be constructive. Don’t burn people down.

1.10 The Matrix

As project manager you are dealing with and are part of at least a two-dimensional matrix.

The people in your project normally belong to another organization, such as a line organization (department in the table above), and will only be under your “command” during a limited amount of time. This often means that you as project manager also need to give feedback to the (line) manager of these persons about their project performance.

The project and line managers should be considered to be at the same level and be willing to share authority, responsibility, and accountability.

While project managers and line managers are considered to be “equals,” senior/executive management (sponsor for instance) and other management stakeholders are needed to provide advice and guidance to the project manager. This management is also needed to take decisions at the required levels and work behind the scenes to enable you to execute your project.

1.11 The Project Impact

A project is intended to change something. You could consider a project as in fact a (big) change that can cause resistance for people who are impacted by the project. Normally people don’t like changes when for instance the way they are working is changed. They are used to that and a change will not always be appreciated.

Let me take a concrete example from my own experience.

IBM bought a company that was supplying ICT services to a number of other companies within a holding. These people were located at the same premises as a number of companies they were servicing. These people had some special perks, were living close by, had their own desks (with personal belongings such as pictures of their family), the office was located in a nice and green town, etc. There was a strong bond between all these people and the other companies.

My assignment was to move approximately 250 people to a new office with an entirely new concept (flexible workspace also depending on your activities at that time, very limited amount of desks assigned to specific people), integrate them within IBM using the IBM ways of working, tools, etc. Staff can also be assigned to other IBM projects and external clients.

Move the data center without disruption and unbundle the organization from the current environment (especially network, data communication connections, etc.).

This was a huge change to people, which had an impact not only on their normal operation but in many cases also on their personal situation (e.g., more travel time and not by bike but by car which also had an impact at home because the car was not available anymore for the other family members in case they had only one car).

As you can imagine there was quite some resistance. Ask yourself what is THEIR problem? Why are they resisting? This is rather often the social impact of the change/project.

People don’t like uncertainty. People don’t like letting things go especially when they don’t know the new situation. This requires empathy of the project manager (and other management stakeholders) and emotional intelligence.

My approach was to involve people directly from the beginning. Really listen to them and show empathy.

Make a presentation at the very beginning to inform them and show “what’s in it for me” from their point of view. What are the benefits for them? Show them the new working environment as soon as possible. Ask them for ideas. A chat at the coffee machine might be very informative to hear what is going on in their minds and what their concerns are.

And . . . communicate! People are uncertain what is going to happen so communication is even more crucial!

Communicate frequently such as biweekly on a particular day. Create an electronic environment for communication, and a newsletter for instance, where you show things like pictures of the new environment, the project planning (high-level steps at least), what has been achieved, what are the planned activities for the next two weeks, thank people who have made a contribution and invite people to contribute, etc.

Arrange budget for celebrating successes and organize a special event after the project has been finished (hopefully successfully) for all people who have participated/contributed in/to the project.

1.12 Sustainability

People are becoming aware of the impact of humankind on our own environment both on short and on long term. Lots of companies have corporate social responsibility (CSR) programs and support (local) organizations in different ways such as donation of funds, products, and offering volunteers to help organizations.

CSR has been defined by Lord Holme and Richard Watts as: “the continuing commitment by business to behave ethically and contribute to economic development while improving the quality of life of the workforce and their families as well as the local community and society at large.”

The objective is to create a positive impact on society while doing business.

This can be seen as improving qualitatively (the management of people and processes) and quantitatively (the impact on society).

Doing business nowadays is more than generating revenue and profits only.

CSR can be seen as a form of business aimed at economic performance (profit), with respect for the social side (people), within the ecological parameters (planet): the triple P approach.

CSR is not “hype” but the new way of doing business. A modern business is part of society and is formed by the people working in this company. The Organization for Economic Cooperation and Development (OECD [8]) has drawn up recommendations for CSR, the so-called OECD guidelines. These guidelines make clear what governments expect the behavior of companies to be by following these guidelines.

Many companies have a CSR program that will contribute to a better society.

Three CSR dimensions:

1. The values that a company stands for. These are often described in a code of conduct and in the so-called “compliance rules.”
2. The social responsibility of a company: the way a company conducts its core business and takes responsibility toward the environment and social context. Many companies describe their activities in this area in a sustainability report. It is increasingly common to have such a report. The directive of many companies in this area is the motto “People Planet Profit.”
3. The social responsibility of a company: the way the company gives something back to society. This subject sometimes gets attention in the sustainability report. Many companies choose not to actively communicate. Activities in this area include employees in a company volunteering time to contribute to a charity or sponsorship.

As project manager you can also have a look at your project and determine/define the impact on the environment, which could be seen as the project social responsibility.

A concrete and simple example is to replace traveling as much as possible by video conferencing.

1.13 Requirements

Why a special section about requirements? Well, this is one of the main causes of project failures. Requirements are rather often unclear, not SMART (specific, measurable, acceptable/assignable/achievable,realistic/relevant, and time related/bound), incomplete (forgotten functionality), ambiguous, and so on.

Repairing this during project execution is very expensive; of course the costs increase quickly over time, very often causes rework, causes irritation, increases pressure on people, and many other negative effects. One way to deal with “flexible” requirements is using agile methods and so small steps for development cycles.

The challenge is to keep the overall picture and objectives in mind.

It is advisable to assign priorities to requirements, and of course these priorities could also change during the course of the project, based on MoSCow analysis (Must have, Should have, Could have, or Won’t have for now).

Requirements are normally split into at least functional requirements and nonfunctional requirements.

Functional requirements can be described for instance by means of “use cases” which describe from the user perspective what the system needs to do.

Nonfunctional requirements describe the environment of the system.

An example of a standard list of nonfunctional requirements is detailed in the table that follows.

 

1.14 Solution Design

Projects that are outsourced to other companies, for instance, very often follow a particular process:

1. The client submits a request for proposal (RfP, or request for information, RfI) to a number of companies which could execute the project and deliver what has been asked for.
2. The supplier needs to verify the requirements and come up with a solution.
3. This solution (result of a solution design process) will be reviewed by a number of (internal) organizations of the supplier such as:
   1. The delivery organizations
   2. Pricing
   3. Legal
   4. Quality assurance
4. After all approvals have been given during the bidding process, the client will receive the project proposal for review and acceptance or rejection.

The entire proposal/bidding process is normally managed as a kind of project as well. This could be for instance managed by a “bid manager.”

The solution design process is normally managed by an architect or total/technical solution manager (TSM).

The TSM not only designs the entire solution but also collects the costs of both the project development and the maintenance phase (business as usual).

During project execution, the TSM should remain available because of the possible impact of changes on the design, costs, etc.

For you as project manager, this solution design is also one of your key documents! Compare the solution design with the design of your house. This design is used by the contractor to build your house.

Note: A number of methods for solution design are available. One of these methods is the TOGAF^® [9] framework, which is the “de facto” global standard for enterprise architecture. The Open Group Architecture Forum, comprised of more than 200 enterprises, develops and maintains the TOGAF standard and publishes successive versions at regular intervals.

1.15 Quality Management

Quality management is an overall activity from the beginning up to and including the end of the project. Quality is the responsibility of every person involved in the project!

The ISO (International Organization for Standardization [10]) 9000 definition of quality is in fact to which degree a set of inherent characteristics fulfills the documented requirements.

Prince2 is derived from the ISO 9000 standards but focuses on project work.

The way I see quality management in a pragmatic way:

1. State what you are going to do.
2. Do what you have stated you were going to do.
3. Show what you have done.

Project assurance should not be performed by someone within the project in order to be able to perform independent project performance and product reviews.

1.16 Management versus Leadership

The way people were managed 20 years ago is different, hopefully, than the way people are managed today (maybe in some cultures this is not the case).

Colenso made an overview of leadership versus management [11]:

The big difference is that with leadership people are involved and motivation is more important. Management is focused on creating output by means of tasks. Of course the way this is achieved might differ a lot. In the army, for instance, there is not a lot of discussion . . . just follow orders.

Dixon [11] describes the difference as: Leadership is the ability to influence the attitudes and behaviors of others. Management is the formal process of decision and command.

Personally I think that today “cocreation” is the modern approach. Together you make “it.”

Together Everyone Achieves More (TEAM).

1.17 Management Style

Many books have been produced about management style during decades such as by Douglas McGregor in 1960 where he introduced his “X/Y” theory [12]. In this theory, there are two kinds of managers:

1. Type X who assumes that employees are lazy and must be forced to work.
2. Type Y who assumes that hard work is natural for employees and that they can be trusted to perform their job well.

Other management style theories have been developed by for instance:

1. Blake and Mouton (1964 [13]) – the managerial grid.
2. Hersey and Blanchard’s (developed throughout the 1970s/early 1980s [14]) situational leadership.
3. Tannenbaum and Schmidt (1973 [15]) – the leadership continuum.

Ichak Adizes [16] did publish his view in the 1980s of four key roles for managers. The majority of the managers would naturally use one of these four and that every manager would have a preference of the use of these roles.

The new view of Adizes is that the four roles correspond to four management styles, and by identifying the role order and preferences you should be able to determine your own preferred style. To be an effective manager, you should balance your actual style across the four (depending on the current situation).

The following roles are distinguished by Adizes:

1. Administrator. This role fits with people who like to plan and organize. Creating procedures, guidelines, etc., is what they would like to do. They follow the book to achieve their objectives and milestones.
2. Producer. This role fits with people who like to produce results to meet the objectives. They are task oriented.
3. Entrepreneur. This role fits with people taking risks and who are thinking. They create and develop ideas themselves and use the ideas of other people. They have energy and want action.
4. Integrator. This role fits with people who are social and like people to get involved. They get people together to build a team.

Below an example of a series of management styles:

1. Autocratic. This type of style manager likes to have maximum control and take decisions themselves. The subordinates just follow orders and are not consulted.
2. Democratic. This type of style manager encourages subordinates to get involved in the decision-making and problem-solving processes. He uses their knowledge and experience to make the final decision. The subordinates have the responsibility to complete their tasks by means of their own views.
3. Bureaucratic. This type of style manager applies tight procedures and lives by the book. It doesn’t matter if this is working or not. The subordinates just need to follow the book. Compliancy is the keyword.
4. Laissez-faire. This type of style manager gives the subordinates space to determine themselves what they do and how they do it. The manager sets due dates, etc., and gives them the freedom to deal with the work in their own way. The power is given in fact mainly to the subordinates. The manager has more of a role of a coach and the supply of information.

I realize that it also strongly depends on the type of organization, culture, and circumstances of which type of management is applied. When you are in the army in the middle of a battlefield there is not much room for discussion . . .

Furthermore, you will experience that you have more than one type of style and that you will apply these depending on the actual situation. Getting closer to a deadline could require a different style than when you are in a project definition or solution design stage.

Finally I would like to make you aware of the situation when you are managing a virtual team spread all over the globe, which is rather common within large companies outsourcing work to low-wage countries.

There is little chance that you will meet all your team members in person. Rather often meetings are organized by means of conference calls with voice only. This implies that the majority of communication, nonverbal, is missing.

It becomes even more complex when you are having a number of people from different cultures and with different languages in the same meeting (or conference call). I think it is not possible to give a standard solution in such a case. Use your knowledge, experience, and what feels good for you (gut feeling, intuition).

You could prepare yourself better by trying to understand the different cultures beforehand. A rather practical book in this context is Kiss, Bow or Shake Hands by Terri Morrison, Wayne A. Conaway, and George A. Borden [17].