PMO – Standard Operating Procedures

In addition to the Project Management methodology, the PMO needs a set of policies and procedures for proper functioning. I call these the PMO's Standard Operating Procedures (PMSOP). The difference between these policies and procedures and the methodology is of scope: the methodology refers to one project, while the standard operating procedures are covering all projects and the relationship between the PMO and the rest of the organization, as described below:

Standard operating procedures and the project management methodology

In addition, the policies and procedures customize a methodology that can be too general to the particularities of the organization which owns the PMO, defining the various roles involved in decision-making processes, the tools used and the timing of activities. A set of such processes and procedures, without claiming to be exhaustive, is presented below:
  • The transition process from business case or offer to project execution – when the project is entering the PMO. If the bidding process or the elaboration of the business case does not happen in the PMO, then you need a clear procedure for the Project Manager assigned to the project to acquire all the information and artifacts that have been defined. If the Project Manager was not involved in the construction of the project, it is quite likely that there will be differences of opinion between the originally proposed approach and the vision of the Project Manager who will implement the project. The Project Manager will identify and attempt to correct the problems prior to starting the project, such as clearly defining scope and project objectives and budget re-estimation. Therefore, the recommendation is that the Project Manager should be involved from the phase of the tender or business case, to avoid these changes and differences. It is even recommended that the same Project manager who will implement the project is involved in the construction of the project, but due to lack of predictability that can occur when approving the project, it is difficult to achieve this in practice;

  • Project Managers recruitment procedure provides assessment criteria to interview people involved in assessing candidates, compensation and benefit scales for different levels of seniority;

  • Capacity planning procedure for the PMO is based on income forecast for organizations that run projects for external clients, or on the business plan of the year for internal projects;

  • The procedure for allocating and communicating project managers' allocation within the organization. Strict allocation rules are difficult to define, but I've seen being used these four approaches:

  • an allocation based on the technical expertise of the Project Manager
  • - is an approach I do not use because I work for an integrator that has all kinds of solutions in portfolio, that could'nt possibly be all covered by the Project Management department;

  • an allocation based on business expertise in the beneficiary’s activity
  • – in my opinion, this is the best approach because only by understanding the business objectives, will the Project Manager be capable to set the correct direction of the project, to support the deliverable to the customer and to determine appropriate corrective actions;

  • an allocation based on personal relationships between the team and the Project Manager assigned
  • - although not a very strategic approach, this can also constitute an important factor to the project's success. If a team is already formed and the risk of conflict is low, all forces will be directed towards achieving the project objectives;

  • an allocation based on availability
  • - is not good idea in theory but in practice is the most used although the results are often disastrous. A competitive business environment that does not allow for spare capacity often forces the PMO managers to make such decisions. Therefore, it is important for the project managers to quickly adapt to different project domains: to have a solid technical base, to understand business administration and to quickly catch the specificity of the client. The management style of the Project Manager must also be flexible, in order to allow them and work with diverse people and adapt their management style on different personalities. Project managers with all these qualities are obviously hard to find and very expensive.
    • The procedure for reviewing and approving the budget and project deadlines in PMO - which would bring accountability to the Project Manager assigned to the budget and time limits. As explained above, if the project was approved following a business case that includes project objectives and a budget and time allocated, it is likely that a newly appointed Project Manager will not fully agree with how the project was initiated. In theory, the project manager has the right to review all these premises and to require a new baseline, usually with a larger budget and / or a longer time, fundamenting the requirement. This is the condition for a Project Manager to be 100% convinced that the project can be successful. In practice, the pressures to fit in the originally approved budget and time will be huge. The project may come from an offer already accepted by the client, which can not be withdrawn and was created to fit into what the customer finds to be reasonable. Therefore, this procedure is often reduced to a record where the assigned Project Manager states the risks seen in the original premises of the project and try to minimize them from the beginning. From this point of view, even the simplified version of the procedure is extremely valuable. It is therefore important that the Project Manager, although he is always put in a position to solve some problems he didn’t cause, to realize that this is one of the reasons why we need project management; it is their art that is needed to lead to a successful project despite initial difficulties.

    • The revision of the applicable Project Management methodology - we call this the tailoring of the Methodology. This review must occur every time with the initialization of a project. It is then when the Project Manager decides what parts of the methodology applies to a project, considering its size specificity, taking into consideration lessons learnt from other projects and deciding the lifecycle of the project, in the same way that the driver imagines a mental driving route after consulting a map;

    • The revision of the project scope and its completion criteria - this review must occur every time a project is initialized. This activity is closely linked to the bullet above: it is possible that the objectives are not clear enough, or it is unclear where the project stops, what is and what is not part of the project. This is where the Project Manager, using techniques such as Work Breakdown Structure helps the beneficiary to limit scope. A word of caution: this activity is often viewed with suspicion by the Beneficiary as an attempt to deny what it was originally "given" in the business case, so it is very important to explain that it is in the interest of the project to allow the team to focus on what is important and to be sure goals are achieved;

    • The initialization of the project in the Project Management Information System (PMIS) is highly dependent on the internal systems in the organization;

    • The procedure for quality audit which is usually included in the Project Management Plan;

    • Financial policies for:
      • revenue recognition;
      • method for the calculation of the percentage of completeness (point of completion) - with direct impact on revenue recognition;
      • method for revenue forecast;
      • an allocation of revenue among multiple profit centers;
      • management of budget changes;
      • a reporting calendar.

    • The procedure for entering timesheets for the project. It is very important that team members enter timesheets daily or weekly. This is difficult to achieve if the company is facing operational overload, because people leave timesheets at the end of the month as a formality for the payment of wages;

    • Work at risk policy, or how to manage the situations when work starts before the contract or the delivery order is signed. The company will have a policy that states to what extent it can allocate resources without a firm order, if some form of a written document from the customer is required (eg a requirement to start work on the email) and to what level of expense (ie no more than 100 man/days). This policy may also contain conditions for client screening, e.g. if the client is recognized to be  a client with a previous good work relationship. A special approval chain for such situations is usually stated;

    • Procedure for reporting project progress;

    • Portfolio analysis procedure;

    • Standard work plan structure, that include activities that are often forgotten, such as activities under the responsibility of the Beneficiary, change management activities or regular meetings;

    • Risk assessment procedure, that includes practices used elaborate the risk log, to such as: brainstorming with the whole team, brainstorming with the customer for a complete picture;

    • The procedure for obtaining the necessary human resources for a project, their identification and contracting;

    • The procedure for the procurement of goods required for the project;

    • The procedure for closing the project and releasing resources;

    • Documenting lessons learned and their dissemination in the company, the decision to include lessons learned in project methodology, since Project management Methodology should contain the result of those practices that have already met with problems and specificities of various projects.


    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.


    Agile Application Implementation (AAI)

    So I am an IT Project Manager and a huge fan of Agile. I made it a must to try Agile for application implementation and with time I gathered a mix of techniques that really work and I would like to share with the PM community.

    Application Implementation refer to installing, configuring and maybe customizing an existing software product (or application); such as an ERP or a Document Management application.

    Most of the outdated methodologies around advice to first run an analysis where you capture all the requirements of the users, then you design the solution, then you implement it and then you test it. You know the drill. This is what I call a Requirements Driven approach: you try to map an application to the needs of a customer. Considering that the application has already been developed to fit the requirements imagined by its producers, this approach seems like a bit of a nonsense to me. Nor does it work in practice, and I've seen many colleagues Project Managers struggling desperately to fix the problems this approach brings. And what it does is induce heavy customizations and all the risks associated with custom development: uncertainties regarding effort estimations, lack of flexibility to changes in the business processes and a prolonged testing process that requires a team of professional testers before the application can be handed to the key users for User Acceptance Testing.

    I use a different approach that they call an Application-Driven approach that is derived from Agile and DSDM (Dynamic Systems Development Method). As opposed to a Requirements-Driven approach, where the project starts with documenting the requirements and then the application is customized to answer the requirements, the Application-Driven approach is based on using a Gap Analysis technique rather then a holistic analysis. So the first step is to show the application as is and document only the gaps. This leads to minimizing the customizations and using the standard functionalities of the application (yes, it is that simple). This approach has the following benefits:

    Decreases the Total Cost of Ownership (TCO) for the clients since it limits the effort to maintain the customizations;

    Shortens the length of the implementation project;

    Reduces the risks associated with the project by eliminating the risks and uncertainties that are specific to custom development;

    Reduces the effort associated with the project through using development only for integration and light customizations;

    Reduces the length of the future technological upgrade projects (e.g. migrating to a superior version of the implemented product, changing the infrastructure), because there are a limited number of customizations to be ported and retested.

    The approach is based on three iterations:

    Vanilla is the first iteration that exposes the users to the application as it is, with only a minimum set of configuration resulted from some initial interviews. The application is presented to the key users during several workshops. The functional consultants document the gaps between the requirements and the application;

    The pilot is the second iteration, with the application configured to answer as many gaps as possible without custom development. This application is again presented to the key users and the key users get to agree on the resolutions of the gaps;

    User Acceptance Testing is the iteration with all the gaps solved, including the ones that require development. The key-users test the application and they give acceptance for go-live.

    Although I use iterations, I divide the project into distinct phases, each phase having a purpose and a set of document deliverables resulting from specific activities.

    Analysis: The purpose of the analysis Phase is to obtain a unique set of gaps between application and requirements agreed by all parties involved. This is done by exposing the standard application (Vanilla) to the key users during several workshops.

    Elaboration: The purpose of the Elaboration Phase is to configure the application to answer as many gaps as possible and to present the configured application to the users.

    Construction: The purpose of the Construction Phase is to develop the interfaces and customizations if any, to prepare data for migration and to develop the import interfaces if they are not provided in the standard. I usually import a set of test data to have it ready for the UAT and also to decrease the risk of any surprises during import for production.

    Transition: The purpose of the Transition Phase is to run the User Acceptance Testing, to provide the training for the key users and to prepare the system for the go-live. Also, I run an import test on the entire set of data needed for production. Then I prepare the production environment: install, configure and import production data.

    Production: The purpose of the Production Phase is to prepare the system for the go-live. Some data will need to be imported just before go-live, the old system must be decommissioned and replaced by the new system. Users and access must be granted. I also run some non-transactional tests on the production environment (non-transactional means no saving - so there are no traces left; usually it means going through all functionalities and make sure forms open and user can access all functionalities).

    I have listed below the deliverables I typically use for an application implementation.

    AnalysisGap Analysis document - Describes the gaps between the standard application and the requirements of the Client.
    ElaborationApplication setup document - Documents the client specific configurations.
    Gap Analysis (Updated) Documents the solutions for the gaps.
    ConstructionTechnical documentation of the developments - Documents the custom developments (if any)

    Data Mapping document - It provides the mapping between the source of the data and the future system's tables.
    UAT Test scenarios - These are the agreed test scenarios that will be used during the UAT.
    TransitionUAT Results - Documents the results of the User Acceptance Testing.
    User manual - Documents the utilization of the application.

    Enjoy AAI!


    PMO’S Organizational Impact

    The introduction of Project Management and Project Management Office has an organizational impact that should be monitored carefully in order not to adversely affect the company. Many effects are not seen in the early months after create structure, but appear after some time of running. The most common problems are:

    The exponential growth in the number of staff from the PMO: As it operates, the organization is transferring more and more work within the PMO, considering that this will raise even more the benefits it provides. Top-management, that can now trust the new structure, will address to the PMO for convenience, instead of requiring that work should be carried out within departments. This is not always beneficial; for acquiring real maturity in Project Management, the entire organization should learn to work horizontally and Project Manager should have less work to do, not more;

    Bureaucracy: In an effort to gain control of the department acting as a company within a company, a PMO Manager will create a lot of reports, policies and procedures to force departments to formally give control to the project managers and to enforce double subordination. With time, these rigid papers should be replaced of communication, cooperation, guidelines and a minimum of paper;

    PMO involvement in all activities of the organization: With confidence gained in the PMO, top management will tend to assign all sorts of activities to the PMO, which will lead to a bottleneck of its activity and an overhead of communication unjustified by benefits. In this respect, some limitations should be established PMO activities such as:
    - the value of the project;
    - project duration;
    - involvement of two or more entities (departments, suppliers);
    - Risks for a company;
    - If the goal is critical to the company (eg a new product launch before the holiday season).

    Special attention must be given to cost reduction initiatives. If you want to maintain the for the PMO medium and long term, do not declare such an initiative as a project for the PMO. Resistance to a measure to reduce costs will be added to the resistance to the new way of working and will compromise the PMO and the definition of Project Management. Rather, approach this initiative as a target for each department manager to reduce costs in his department and for the PMO to improve inter-departmental processes to achieve synergy.

    On the other hand, with the establishment of PMO, executives and managers should quickly find the following qualitative benefits:

    The number of conflicts and problems escalated at your level dropped because it was filtered and settled largely at the Project Managers level;

    The time required for finding information on the progress of a project decreased. Without PMO, the information on the projects are scattered throughout the organization and there are multiple formats for planning. With the standardization brought by the PMO, status meetings are shorter and more revealing;

    Decisions on strategic initiatives are difficult to take in the absence of a PMO and are often delayed. With a PMO, data are available and decisions are possible.

    Time spent in meetings is shorter when there is a contact point that has for information, knows the issues and know who and in what meetings should be involved. As executives, you have the opportunity to spend less time solving operational problems and more time in strategic meetings.


    On Project Management Office

    I am on vacation, so I will be blogging a lot :).

    Today it's on Project Management Office. We will discuss in later posts about its impact in the organization and the Project Management Information System.

    The concept of Project Management Office was introduced in this post as a structure that is established when a company reaches a certain level of maturity in terms of Project Management. PMO can be established even earlier by a visionary executive management, but then the journey of this structure will be longer and more difficult, until the organization matures to allow for proper functioning of the PMO.

    What does actually mean a Project Management Office? The meaning of the PMO might vary, according to senior management vision who needs to define and explain the objectives of the PMO to the rest of the organization. An example of the mantra of the PMO is described below.

    The role of the Project Management Office is to supervise all activities of Project Management and to ensure standardization and predictability in how projects are run. Standardization is ensured through the use of a single project management methodology, and predictability is ensured through regular operational processes such as: Revenue Forecast, Progress Reporting and Portfolio Analysis.
    In terms of the PMO and project managers, departmental lines are transparent and decisions are related to the whole portfolio, rather than at the department. For senior management, PMO provides the information necessary for optimal planning of resources, especially human resources, and access to any information required on the project. PMO is the single point of accountability on projects in the portfolio.

    We underlined in the above description the word "predictability", which is very closely related to standardization. These are key words in a company, because they provide control over the future of the company. The stock exchange or the investors appreciate the quantitative indicators (eg, income or profit), but also the predictability of a company's financial statements as compared to the forecast. Any variation is perceived as a risk to the company's shares of stock in question and is penalized by a decrease in share price (for more information see the course of "Investments").

    How is this linked to project predictability? In the case of organizations delivering services and solutions customized in a B2B model (business 2 business), projects provide the vast majority of revenue and profit. It is clear then that their financial results are as predictable as the Project Management activity, depending on delivering and billing projects as expected.
    If organizations are not project-oriented, the projects are actually initiatives to create new products or make changes (improvements). In any case, the ability to run successful projects and completing projects on time is the company's ability to keep up with competition, market and industry. The relationship between healthy projects and financial results is more subtle and it is more difficult to demonstrate an impact on profit for example. It is therefore important to look at projects’ Return on Investment (ROI), and to determine the opportunity cost in case of failures or delays, to motivate management to provide resources to projects.


    Planning for change with Agile

    Change is inevitable during projects. Many Project Managers, and Customers, wrongly interpret scope and change control procedure as methods of limiting the change, when can actually be tools to facilitate change, while maintaining control over the project. The change control plan is developed since the startup of the project and it is a good idea to communicate with the client at the kick-off meeting how change will be addressed during the project.

    During project implementation, priorities change, new elements can occur that during the analysis were omitted, that are implicit requirements or that no one thought of. If you choose to implement using an iterative method (e.g. Agile), which implies presenting periodically the application / product to the client, changes will occur earlier. If the approach is sequential, meaning to show the client only the end result, these changes will be deferred until final acceptance, which increases the risk of the project. In an iterative approach, the client sees an intermediate product and is able to work with it (even for testing purposes), so they can tell when some functionality was forgotten.

    As change is inevitable (many say it is even recommended) under the pressure of the business environment today, which is in constant motion, why is Project Management sticking to the old, un-flexible way of doing business? Why not admit that change will happen and plan for it ? What can be done about it?

    First, consider how being unflexible about change might cause tensions with the client. And we can identify two cases:

    The client failed to include important functionality but allocated all budget. They want the missing functionality to be included, or the system will not be useful for them, but the zero budget constraint blocks any change;

    The review of the project scope has "grey" areas that lead to interpretation.

    One solution in such cases is to introduce the new requirements and remove the less important features not yet implemented, so that efforts to implement the new functionality will be equal to the ones out. This means to have (or will have to create) a list of product functionality, ranked by their importance. It will be much easier for the customer to decide what features can be removed, starting with the end of the list. This is called a MOSCOW list in Agile. Agile can help with spotting implicit requirements as well, early in the project, by exposing the customer to the product in early stages of the project, so that the client can pin-point if something important is forgotten.

    Another important method by which we can prepare for change is to advise the client that they keep a part of the budget for the times when extremely important features are found but were not expressed in the initial scope. A good rule of thumb is to have this contingency at about 10% of the project. This will create a comfort for the project team from both the client and the provider that there is a solution for crisis situations and the whole team will focus on achieving all project objectives and carefully using this contingency, and not searching for ways to defend their position. In my experience, fully allocated budget with the assumption that everything will go according to plan ranks among top 5 reasons for project failure. That is why, when in a project that is in difficulty, I always advise the client to budget 10-20% for change requests. It is not a lot, after all the work and the struggle of the project, and lifts a lot of tension from both the client and the provider, leading to a normal working environment and quality results.

    Finally, a Project Manager should introduce these mechanisms at the proper time. The easiest method is to discuss this possibility with customers early in the project, namely during the kick-off meeting, or even earlier if possible.


    Set expectations from the Steering Committee

    Handling Steering Committees requires managing up, which is why it is very important to communicate your expectations and obtain commitment from the senior executives that they would act as such. In order to make the Steering Committee an escalation mechanism that works, present these simple rules and obtain agreement on them:

    1. Issues that are escalated to the Steering Committee are:
    • Discussed with the Project Management Team and a solution has been attempted;
    • Not within the Project Management Team power;
    • Resulted from private agreements and discussions that the Project Management Team has not attended; 
    • Important effort/time can be saved if escalated early.
    2. What each member of the Steering Committee should do with regards to problems:
    • Brainstorm for solutions, contacts or resources;
    • Make decisions or take actions to solve problems ("make that phone call");
    • Assume responsibility and get involved.
    3. What the SC is not:
    • a wall that bounce back problems to the project team: issues should result in a resolution;
    • a place to "shoot the messenger";
    • a place to make the Project Manager an "escape goat".
    Since Steering Committees are about managing up, and practically all initiatives in corporations are projects, these rules can be used also to govern any escalation mechanism, board or committee. Find here the slides for such a presentation; you can use them for the kick-off meeting for instance.

    A word on Steering Committees for project in crisis: If your project is in crisis (or you have assigned a red flag to it due to its many risks), proper and often function of the Steering Committee is vital. Make sure to establish the Governance Mechanism using this post I've wrote, but make the frequency to be at once a week (that's right, 1 time per week), and note that for project in crisis, it's critical to escalate issues early. So paragraph number 1 becomes:

    1. Issues that are escalated to the Steering Committee are:
    • Important effort/time can be saved if escalated early. (nothing else matters)
    It is also critical that a senior manager gets involved on a daily basis, and so paragraph number 2 becomes:

    2. What each member of the Steering Committee should do with regards to problems:
    • Get involved, assign at least 1 senior member to get involve daily.


    How the Executive Management Should Get Involved in Project Management

    Why is it difficult for organizations to move ahead towards implementation of professional project management processes? For some of the following reasons:

    • Project management appears to involve the shifting of the poles of power, taking power from functional managers and giving power to the Project Manager (this is only partially true, since functional managers will actually be the first to benefit from Project Management);
    • Project management involves horizontal control with regards to the financial implications and on how each team member carries out his work on the project. Success of the project is the responsibility of Project Manager, and therefore lack of performance can not go unnoticed;
    • Project management involves what may be perceived as an overhead devoted to planning, reporting, financial accounting, etc. This effort cannot be done by the Project Manager alone, but only together with the team. This leads to frustrations that Project Management is actually an increase in overhead and bureaucratization. 
    Therefore, executive management involvement in the above levels of maturity is required in order to achieve the acceptance of the organization for the objectives and processes for Project Management.

    Executive management must visibly support actions to establish concepts of Project Management in the organization, or the other employees will think the higher management is not convinced of the necessity of this action, the functional managers will be reluctant to give support to the project managers and the entire process will be hindered. Often, perception is formed even in the executive managers‘ eyes that the Project Management "does not fit with our organization" and the whole process may eventually be abandoned.

    But why is it important for executive managers to implement project management processes? In organizations where the concept of Project Management function effectively, the role of Executive Manager change. Initially, the executive managers were involved in carrying out everyday projects, especially in terms of initiatives or strategic customers. But as project management matures, executives get a more passive role, allowing them to focus on what should really be their job: planning and long-term strategy. As they gain confidence in the Project managers, executive managers increasingly rely more on them for daily decisions and consider Project Management has a fundamental role in ensuring the success of their organization.

    In conclusion, a mature organization in terms of Project Management is manifested by:

    • Understanding Project Management's benefits up to the Executive role;
    • Continuous and visible support from senior managers for Project Management;
    • A desire from senior managers not to get involved in the daily activity details and to rely on Project Managers to provide high-level information relevant to them.


    Project Management Maturity

    The model of Project Management Maturity consists of five levels, although it is often found that these levels overlap and there is no clear borderline between them. They are listed below and will be detailed in the next subchapters.

    Levels of Project Management Maturity

    1. Intuitive Project Management

    In this organization, the Project Manager is not yet recognized as a distinct professional. The initiatives are run as projects in an intuitive fashion by the most enthusiastic team member. This team member has a strong desire to succeed and self-appoints as being the one responsible for the project (this is how a Project Manager is born). This leader will use some empirical planning techniques and sometimes bypass the planning all together because everyone is looking for seeing some “real work” done and some quick wins. It is unfortunately to find that of the initiatives run in this fashion will die out, especially when they are run for an internal client, or will have difficulties in reaching the completion point. This is due because nobody takes the time to initially define in a clear fashion which should be the end result.

    However, there is an advantage to this approach. This type of Project running will not provoke resistance from the hierarchical organization, because the project team and its leader will be usually located inside of the same department. Working as a project team is natural and there is no need for an organizational culture shift in order for the project to be managed.

    For the organization to jump at the next level, the top management needs to recognize the Project Manager as a stand-alone profession and prepare some training for the project teams that will facilitate understanding how the projects should be run. The most frequent reactions to this jump are coming from the team members and functional managers, and will most likely sound like this: “Formal Project Management does not apply to us” or “We are doing fine without it”. On the other hand, executive managers will know this organization favors silo-decision-making: decisions being at the department level, that are good for that department but are not optimal for the organization as a whole. This organization will make interdepartmental initiatives’ fail out of lack of authority and organizational change will be impossible.

    2. Acknowledged Project Management

    After a few failures of the strategic initiatives and seeing the inability of the isolated departmental teams to induce change on a organizational scale, the senior management will look for a virtual team that comprises members from all departments that are targeted by the project. They will also look for a single point of contact, responsibility and information. The Project Manager title will naturally emerge, very often as an extra-hat next to the functional title. Team members will now report to multiple bosses, which will cause the first reactions of resistance, like some sort of indiscipline for the work related to the project. This makes communicating of the first successes very important: they can be about cost reduction, shorter implementation timeframe for the same quality and scope, or an increase of customer satisfaction. This is the point when senior managers should ensure there is a continuous flow of projects and look for best practices and lessons learnt being applied in the next projects running.

    As costs distribution on projects becomes necessary, the accounting system needs changes to accommodate this requirement. It becomes visible where money is spent without justification, and pressure is put that not only should projects be successful and in time, but that they should be cost effective too. A lot of company cannot jump above this level because of the inner resistance to controlling costs in projects (horizontal accounting).

    3. Project Management Methodology

    Acknowledging Project Management as a stand-alone profession is a huge step, but projects will be run in a more or less successful fashion until some crisis strikes that requires the superior management’s attention. This is the point when top management should require documentation on how should ideally a project be run. This documentation should comprise of a standard activity list, best practices and Project Management deliverables that will make the success of the project less dependent on the Project Manager’s experience. They will also require a procedure for escalating risks and issues to the upper management levels if this is the case, which will enable corrective actions in a timely fashion. This is how a Project Management Methodology is born. The methodology can be adopted, adapted or unique, as the organization requires.

    This phase comprises the greatest risk for the Maturity in Project Management pathway. It means a major shift in organizational culture and the resistance can be huge, varying from skepticism to nearly sabotage. Top management must show constant support for the Project Management concept during these times. Once this resistance is overcome, the two levels that come will be more natural and less risky. The problems that might be encountered during this phase are typical for any organizational change:

    ü  Conflicts caused by changes in power and authority balance – that is, the Project Manager is seen as getting too much influence and stealing power from functional managers;
    ü  Working horizontally and reporting to multiple bosses is not accepted by team members;
    ü  People might hind behind current procedures and politics in order to justify lack of initiative and extra effort;
    ü  Time is wasted in meetings for conflict resolution, aligning conflictual objectives and point of views and useless reporting to managers who would feel comfortable to delegate authority;
    ü  People might use e-mails and other forms of documentation to hide and pass on responsibility;
    ü  People might fight for resources;
    ü  People might experience a low level of motivation.

    In order to advance from this stage, the management must institute the culture that the methodology is not a rigid set of papers. In mature organizations, the methodology is supported by the entire organization and individual behavior is determined by the philosophy of the methodology adopted. The methodology is not used as an excuse and all members of the organization participate with extra effort if there are problems. Achieving this kind of thinking is especially difficult in fragmented organizations, with different subcultures, which are required to convert their local thinking into a unified and cooperative approach. Culture must be nurturing, based on communication and collaboration, and is therefore important to establish the correct relationship between the Project Manager and rest of the organization:

    ü  Project managers and functional managers are equally responsible for the successful completion of the project. Functional managers need to keep their promises to project managers regarding resources, efforts and deadlines;
    ü  The Project Manager title is a recognized as a stand-alone profession. The Project Manager is no longer the functional manager or the best of the technical people.
    ü  Project managers negotiate with functional managers project deliverables, not people allocated. It is the functional manager’s ultimate decision to allocate the right people in the context of other business constraints;
    ü  Functional managers trust Project managers enough to give them authority over the team and not to intervene in the way the team is run;
    ü  If a functional manager can not achieve the objectives assumed, the Project Manager has the duty to persuade him to seek alternative solutions;
    ü  The Project Manager has the authority to make decisions regarding the project he leads. Decision-making authority and power are decentralized;
    ü  The Project Manager is required to inform the project sponsor and ask them for intervention if required. At the same time, the project sponsor will be permanently available to help, but it will not interfere in the management of the project and will not take decisions in project matters;
    ü  The Project Manager (and other team members) are encouraged to submit recommendations, alternatives and ask for allocation of resources outside the team and even from the senior management team, if this is required to solve problems beyond its authority and in the best interest of the project. These recommendations and requests should be included in an internal project progress report. What you need to include an internal report of progress has been explained in Chapter 13.3 Project progress reporting;
    ü  There is a process of internal progress reporting that runs periodically (chapter 13.3 Project progress reporting).

    The organization has reached the maturity needed to reach the next level when it recognizes the difference between project management and operational management, and that a different set of skills is required to act as Project Manager. The focus moves on:

    ü  Motivate Project Managers to be more proficient;
    ü  Recruitment / growth of Project Managers who excel;
    ü  Increased productivity of the project team;
    ü  Increased productivity of the organization as a whole;
    ü  Establish project methodology as a current practice.

    Achieving this level of maturity does not mean that running totally/only successful projects. It means that they will be run efficiently, thereby maximizing their chances to be successful. Indeed, by measuring number successful projects, top management should be able to see an upward trend. But project management, even at its peak performance, does not solve problems of unrealistic goals or unfavorable economic or organizational context.
    This author empirically considers that this phase, from its initiation until the maturity necessary to move to the next level, might take two years.

    4. Project Performance Benchmarking

    The organization that reached this phase will put a lot of emphasis on measuring project performance and project portfolio performance. Besides the quality of the portfolio can be measured, other aspects can be measure, such as the accuracy of the initial planning, financial forecast accuracy, risk management accuracy, customer satisfaction, quality of deliverables, etc.

    This is the best time to establish a Project Management Office (PMO), or a Community of Practice in Project Management. The difference between the two is mainly about the power of the new structure, the subordination of Project Managers and the list of responsibilities of each form of organization. With a Project Management Office, Project Managers report to the Director PMO, while the Community is a virtual structure having a professional leader, but the Project Managers remain subordinate hierarchical, to the functional manager.

    The difference of functions within each structure is shown below. One can see how PMO’s responsibilities include excellence in Project Management that is provided by a Project Management Community and receives additional functional responsibilities of being the central point and health monitoring project costs (Portfolio Management, post to follow).

    This is also the time when, in order to meet the need for measuring performance of project management activities, dedicated Project Management Information Systems (PMIS) are implemented in an organization.

    Some resistance to change can occur in this phase. The measurements made ​​can be dismissed as erroneous, due to some conjectural factors, and even the original authors of the methodology can withstand measurement initiatives for fear that the results could be bad and can block improvement initiatives, using arguments such as "Measurement is not relevant to us" or "It does not apply to us."

    5. Continuos improvement

    Based on the understanding provided by performance measurement of the projects, the necessary corrective measures can be taken to improve the quality of project management processes. Another objective may be to simplify the methodology and minimize required documentation once the organizational culture was transformed. In this phase, the top management should encourage useful documentation project, clear and efficient communication, minimize emotional conflict, and document lessons learned and improvements to make them available for the next project.

    This is when a personal development strategy is created for the Project Manager, with mapping between levels of seniority of Project Managers and relevant curriculum for them.

    Also, the organization may become interested not only in comparing projects with their own objectives, but also with how other organizations are implementing Project Management, their cost structure and the improvements they make.

    As Project Managers themselves become seniors, and the organization gains confidence that the processes of project management is functional, rigid policies and procedures are abandoned and replaced with guidelines, checklists and reusable artifacts. Both the organization and the Project Manager can enjoy more flexibility, an informal style based on collaboration and cooperation, rather than enforcement. Unfortunately, this goal can be achieved only at the fifth maturity level, because only then can the project management function effectively and without the rigid controls imposed by the policies and procedures. There is o shortcut: all large organizations go through the control phase before they can reach an informal style of Project Management. Even at this level, the senior management must question periodically whether by undertaking informal Project Management, the company does not return to lower levels of maturity, and to balance the need to control with the informal style in order for the Project Management to remain effective.

    Guerilla Project Management for Executive Managers

    Why is Project Management important for Executive Managers? Our daily activities and jobs include Project Management activities, even if they are hidden under different names. This blog is partly about how to run projects, and partly (and puts a great emphasis) on how to benefit from a Project oriented approach, no matter which step of your career you are to.

    Implementing Project Management, meaning implementing a Project Management methodology, opening Project Manager jobs or creating the Project Management Office, is usually an initiative of the top management of a company, because they are in perpetual search of new ways to develop competitive advantages. That is the rationale for this blog being partly addressed to executives: one must know what to expect and ask from Project Management and where is her organization on the path of Project Management Maturity. You will find what is common and what is not in the problems you might experience during this journey, all with the purpose of being successful in implementing Project Management as a competitive advantage.

    Although based on the PMBok methodology, this blog is not destined for studying for the PMP certification. There are far more thorough materials available for this purpose. The best practices (in my opinion) that are described here are exclusively based on real practice and can differ from the theoretical concepts the PMBok describes. They are presented somehow different for ensuring a practical, down-to-earth understanding for people that are not specialized in Project Management.

    Here is how to benefit on Project Management no matter where you are:

    • If you are an executive manager: use Project-oriented organization in order to achieve you business/strategic objectives;

    • If you are a senior manager and work in a company that could benefit from project-oriented approach, use the rationale presented by this blog to see how it can apply to your company and to convince upper management to use a Project Management approach;

    • If you are the Project Sponsor, that is, you pay for the project from your own budget, use this blog to find out how to act as a Project Sponsor in order to maximize the benefits for the money you are paying;

    • If you are a Project manager that has an internal client (that is, from your own organization), find out how to relate with the rest of the organization in order to secure the resources that are needed for the project;

    • If you are a Project manager that has an external client (that is, from outside of your organization), find out what is specific for these projects and how to involve the client for their being successful;

    • If you find your self being a de-facto Project Manager (although your title might differ), use this blog to formalize your knowledge in Project Management; it is my belief that each and everyone of us is a Project Manager, either at work or at home. 

    This blog uses the following concepts as its core:

    • Project-oriented organization and approach: its description and why is it considered sound business practice. How to ensure cross-functional and cross-departmental initiatives success by using virtual teams (Project Management Maturity);

    • Understanding organizational culture needed to reach certain levels in Project Management Maturity, ensuring the context needed for successfully reaching business objectives using projects and nurturing a culture that facilitates quick decision-making and short communication paths within the organization. How to stimulate initiative, participation and group motivation at all organizational levels (post to follow);

    • Understand project definition, the adequate project size and how to allocate a Project Manager that fits the job. Effective management by delegating authority and control to a good Project Manager (post to follow);

    • What means a good Project Manager and how/where to recruit the needed Project Manager (post to follow);

    • Understand what is a Project Management methodology and what advantages it brings if used consistently. Add a complex practice skillset in general planning and managing projects, and use them to create competitive advantages for your organization (post to follow);

    • Understand the project lifecycle: Start-up, Planning, Executing, Controlling and Closing (post to follow);

    • Define a program as an interrelated set of projects with common objectives and interdependencies; manage change within your organization that comes with implementing programs. Learn the level of necessary skills required for running big projects/programs and how can one advance from Project Manager to being a Program Manager (Program Management, Program Governance, Managing Change, Communicating BenefitsChoosing the Right Program Manager);

    • Understand Portfolio Management concepts and how to analyze a Portfolio of Projects (post to follow);

    • How to set up a Project Management Office (post to follow).