Project Management as a company-wide practice

I have often encountered the situation when Project Management is seen as a Project Manager's solely area of expertise. People let Project Managers do their own mambo jambo, academic plans and presentations, while they continue working in exactly the same way as they did before they worked in a projectized organization.

The first obvious difference is at the team member level. They will not only have two "bosses", but they will need to start reporting in project management concepts:
  • how long will it take for a specific activity to be completed (estimation)
  • what progress has been made on the current activities and when they will finish (time to completion)
  • if there is a deviation from the estimation, what actions can be pursued to correct it (financial management)
  • what risks and problems are foreseen at the technical level (risk and problem assessment)
  • what scope deviations are foreseen at their own level (scope management)
  • what technical arguments can be given to persuade the client to chose a certain solution or to understand scope deviation (client management).
Staff in companies that are young from the project management perspective try to resist providing all these information to the Project Manager. They see it as overhead talk. They believe good Project Managers should be able to know all this and do their own stuff without impeding other's work. But what good Project Managers should do is to try to train their team members and make them understand what is required from them in order for the project to work well. The reality is that Project Management does not work if only the Project Manager practices Project Management.

The second obvious difference is at the managerial and support level. For the Project Manager, everyone is a resource in their project, and as her ultimate goal is to make the project successful, she sees Management, Accounting, Sales, Purchasing, Logistics as entities that should cooperate for her project's success. Unfortunately, Management, Accounting, Sales, Purchasing and Logistics don't see themselves in the same way. They often have different agendas that no doubt are important, without realizing that failing to cooperate with the Project Manager results in blocking the project and wasting the work of the PM or an entire team, the fury of the client and delays in obtaining the revenue used to pay their own salary in the first place. This is why Project Management is a practice that is to be internalized by the entire organization, no matter the role in the company.

In some of my recent work, I have put a lot of emphasis on developing a Project Management book aimed at managers and executives and I plan to actually transform it in a course. You can find extracts from the book by searching for the tag "Project Management - a managerial approach". The concept of Project Management with a managerial approach is the same as with any discipline taught in MBA (e.g. Macroeconomics with a managerial approach, Accounting with a managerial approach): a discipline with a management perspective that is as technical as needed for a manager to be able to manage specialists and make the most benefits of it. I plan to continue with some articles on Project Management aimed at Accounting, Sales, Purchasing and Logistics.


Acting as a Project Sponsor

As a senior manager, you will often find yourself in the position to sponsor a project. This either means that you are the beneficiary and the owner of the budget of the project, or that the holder of this budget has invested you to play this role.

Even if an executive manager, the Project Sponsor will get more involved in the project assigned, in order to protect the interests of the project. The level of involvement will depend on the phase the project is, but the involvement must be visible and continuous.

From the inception of the project, the Project Sponsor should be interested that the planning (time, features and budget) is feasible. Their primary interest is to ultimately benefit from the results of the project, which will never happen if the costs and/or timeline are too low compared to the features and quality required.

The Project Sponsor should have a small budget put aside for change requests. Don't assume all tasks will go according to plan. Also, don't add an extra 10% to each activity; have 10% form the entire project put aside as a bulk sum that can be allocate in different proportions where needed. It might come to the time that the project is blocked at 90% because all budget has been spent and this will be your safe cushion.

The Project Sponsor should also be interested in the team: the level of allocation required, the competencies and the feasibility of these allocations. Securing the right resources from the beneficiary is key in the success of the project, even if you have a powerful and experienced supplier.

The Project Sponsor should be concerned on the approach of the project. The most successful projects are built in small iterations, so that benefits can be gained early and there is flexibility for change should the business change also during the project lifetime.

The Project Sponsor should be concerned about progress reporting. They should ask, if not already given, for progress information and status meetings from the Project Manager.

The Project Sponsor should be concerned about escalation and establish clear rules when issues should be escalated to her. I have found that Project Sponsors regretted less if issues were escalated to them too early, and more if issues were escalated to them too late: with a phone call, they were able to solve a problem the PM was struggling with for two days. So as a Project Sponsor, keep an open door for the Project Manager or any Team Member and don't frown even if you feel they escalated to early: it might be because they knew you would be able to solve it in less then 1/10 the time they would take.

The Project Sponsor should take Organizational Change and coping with Organizational Change as their task, since it does not only requires skills that the PM might have but also authority that the PM probably does not have.

And finally, the Project Sponsor should be concerned with maintenance: what to do to maintain the solution, the change, the benefits. This is especially important for the Beneficiary organization, because the project was created in order to improve an aspect of how the business runs in the Beneficiary organization. In addition to the tangible deliverables of the project, the Project Sponsor must ensure that the employees use that deliverables and benefit from them. If change that comes as a result of the project is not maintained, the way the company’s journey will look like the graphic below, where each improvement initially brings visible progress, but after a while, the organization returns to its former level, which is the level of comfort of its employees:

Instead, we want to see progress as shown below, so it is important to endorse the level of change after the project:

If we were to use a Pareto analysis, we can appreciate that the effort required to maintain the change is only 20%, compared to 80% effort required to get the initial momentum. It is therefore very unfortunate that this effort is wasted in many organizations who rush to celebrate the success of the project and then forget about it and its results. Some simple ways to ensure that change is sustainable are listed below:

  • Make changes in small steps, and avoid too much change or change of different areas at the same time, because that would confuse employees; 
  • Even before the end of the project, give great attention to training and communication of project results towards those who will benefit from them; 
  • Change internal rules and procedures so as to include project results in them (for example, when launching a new information system, the job description of the operator must be updated to include the ability to operate correctly and to date in the information system); 
  • Change compensation and benefits packages in order to encourage the use of project results (e.g. at the launch of a new banking product, sales force objectives include a sales target for that product); 
  • Install a post-production support system for those who want to use the project results, but have difficulties - for example a sales person who has participated in defining the product will be available anytime for his colleagues for questions about the product; 
  • Regular audit (announced!) of the change that imposes coercive measures and sanctions for those who do not comply with the measures imposed. It is always advised to use positive motivation, but the truth is that without a set of consequences, employees will be tempted to return to their old way too easily, because this is their level of comfort.


X, Y Motivational Theory and Project Management

I had recently had a number of conversations with different people on the motivation theory of X and Y. Basically, this theory says that there are two motivational approaches managers have: one that assumes people are inherently bad and lazy and need to be managed by fear (X managers); and one that assumes people are inherently driven by good intentions and find satisfaction in working and having results (Y managers). This is an empirical theory, that is not proven scientifically, therefore I can afford to suggest an extension to it. The fact that managers seem to take either one approach or the other can be easily observed in every organization. Based on my observations, what I suggest is that:

1. The theory is self-enforcing; that is: if one manager treats people as bad and lazy and uses fear to "manage" them, people tend to act as expected, by being bad or lazy, at least when it comes to interacting with the said manager.

2. The X management style is not working in the IT field (maybe neither in some other creative fields or professional services fields). I perceive IT people as highly educated, highly paid, self-aware people that have strong values and self respect. When confronted with an X manager, they will willingly leave the company or (worse) stay and perform poorly until they can find a better job.

These two assertions have multiple consequences in Project Management, because as the definition of the project states, the project is "a unique endeavor", by unique meaning that an assigned project team has to be creative enough to find a path from specifications to the finished product. It also means budget or timeline are not necessarily accurate, which presses for even more creativity and involvement into finding solutions and taking the extra-work necessary for the project success. My opinion is that creativity and extra (productive) work don't go well with X, they can only be found in the Y managed teams.

I am a fan of the Y theory mainly because I genuinely find people interesting and I like to treat them with respect. I also try to be objective enough to understand the weaknesses of such an approach. When people happen to have different agendas or are not productive at work because they use their energy on something else, they find it easier to do this under the governance of an Y manager. The art here is to capture such deviations and intervene with assertiveness (by openly discussing and exposing the problem). Still, I believe that if someone is not correcting their behavior after such a talk, there is very little use to try and force them into the desired change (e.g. by changing managing approach to X). This would be like resisting reality, e.g. that the other person does not feel like working on the same agenda as you do (more on Resisting resistance here: http://www.stevepavlina.com/blog/2012/09/dealing-with-others-insecurities/).

So while I address the weaknesses, I still use the Y approach and I can confirm I have better results then colleagues that use an X approach.