Rebaselining is a Standard Operating Procedure for Project Management that refers to the process of revising a project’s budget. A baseline means a set of figures meant to be used as a base for measuring variances and it can refer to many other things besides money (e.g. timeframe, response time, etc). However for the purpose of this document we refer to the baseline only in the context of a project’s revenue and costs ($ and effort expressed in mandays).

Usually, companies refer to baseline as the P&L established during the bid phase (we will call that “the bid baseline”). However, the baseline is not a static figure; once we understand there is no way we can reach a certain baseline, there is no point into trying to measure against it. This is why baseline can and has to be changed once there is information that the original (bid) baseline cannot be achieved.

It may be found that bid assumptions may need to change as a result of the scope validation and project workplan development processes that would have impact on the project’s costs. Or during the project’s execution and control, project financial changes may occur that would lead to the need to rebaseline the project’s budget. These could relate to changes due to rate changes, amendments and/or unforeseen project conditions.

It is the project manager’s responsibility to bring these changes to the attention of management and present a case to re-baseline the financial cost expectations for the project. The project manager would need to obtain approval for the new budget before it can be used for calculating variances and must obtain approvals from the same approvers that approved the original budget to rebaseline the project’s budget, specifying the business requirements for the re-approval.

This policy is not to be interpreted that costs overrun will be easily accepted. Usually, the management will challenge any such request and Project Managers will need to make a good case in explaining their position.

Purposes of rebaselining:
In case of change requests, it is obvious we want to track the project against the whole funding provided by the client.

In case if internal changes or unexpected events that impact the costs, we need to acknowledge them and attempt to control the changes just as we would do in the case the client has initiated the change.

In case of “scope creep” or customer not fulfilling their obligations, the PM will immediately signal this to the client, understand the impact, obtain new estimations from the team and commit to the new estimations. If the PM fails to obtain additional funding for the change and for commercial reasons the team gives away free days, the PM should still inform the retain the amount for giving their company an edge in further discussions.

In case of plain misestimating, the PM must immediately assess the impact, obtain new estimations from the team and make sure they commit to the new estimations. This will allow the management to ensure there will be no further slippage. The PM must also analyze what caused the error in estimating and propose the necessary update in the estimating techniques used in the company.

Triggers for rebaselining

Any Change Request that modifies the Revenue and will be not handled as a different project.
A Change in services costs (own or subcontracted) that is outside the range of +-10% of total costs.
A change in external costs that implies acquisition of new equipment, new licenses or new subcontractor, regardless of amount.
The new baseline must replace the old baseline in the project progress report, while keeping the old baseline for reference.

A good policy is for PMs to inform on a necessity to rebaseline because of costs overrun as soon as they can predict a cost overrun that might impact the budget (that is, before the costs actually occur).


Risk Management at the Source - Part 2 - Monitoring and Controlling

Initiating and Planning provided you with many opportunities to foresee risks and mitigate them early on. If you have not read the post, make sure you do because in Monitoring and Controlling your life will be much easier if you were able to follow some advice listed there. Initiating and Planning is the best project phase for mitigating risks.

If life was tough and you couldn't address the risks at the beginning of the project, there is still a chance you could do it while monitoring and controlling. The techniques used in the monitoring and controlling phase are also useful for the situation when you take on a project after it had begun and had been initiated by somebody else, possibly less skilled then you. The project might already be in trouble if the risks where not address early on, so your main challenge might be to find time for preventive actions while firefighting the current problems. The obvious advice for this situation (and listed in every Time Management book printed) is to work on a Urgency-Importance framework; that is to handle first Urgent and Important issues, then Important but not necessary Urgent issues. It sounds simple, but it takes a cool head and a bird's eye overview on the project to resist pressure to act on the Urgent issues - which is why Project Management requires some maturity.

That being said, here is the promised list of techniques:

  • Include key risks in Project Progress Report and Steering Committee presentations, including expected action plan, deadline and responsible. This might come to you as a no-brainer, however I have seen many Project Managers not exposing risks because they don't want to "upset" the customer. Others, to the contrary, like to give such a list to the customer in order to lower expectations but fail to provide a solution and action plan with them, which makes the customer and the team shrug while no constructive action is taken. Do this also to make sure client and team take risk management seriously and understand Risk Log is not an academic exercise.
  • Circulate Project Memos with regard to risks if in-between reports. This will ensure risks get all the attention and implication from involved parties.
  • Include contingency for highly probable risks in the estimated costs of the projects. This will mitigate debooking revenue due to risks materialized and fluctuations in the revenue forecast.
  • Monitor actions of non team-members staff involved in Risk Mitigation as you do for your project team. That includes monitoring deadlines for project sponsor, client staff, sales staff risk-related activities. Risks are often related to entities outside your project team. Monitoring these entities will mitigate the risk of stalling in important decisions, and that influential people don't timely use their power to help your project.
  • Depending on your delivery methodology, you can use various documents to mitigate risks. For example, use the Testing Strategy to clearly split roles and responsibility between you and your customer. This will ensure the customer not performing their tasks thus delaying the project.
  • Use the Testing Strategy to define testing system information; release procedure, bug tracking procedure, acceptance criteria for application (e.g. “no critical bug, no more then 4 medium bugs and plan of action for all bugs”), definition of bug and new feature request in the testing strategy. Pre-approve the document (gain approval before testing begins). This will mitigate the risks that testing is delayed because of misunderstandings between the development and testing team, unrealistic expectation that the application performs perfectly, discussions over bugs vs new functionalities, unrealistic expectancies that new features will be considered bugs. And in the end mitigate an important risk of all projects - scope creep.
  • Use the User Acceptance Testing strategy to avoid the common pitfall of transforming UAT in an analysis workshop gathering new functionalities requests. You can do that by planning and pre-approving a set of goals, scope and assumptions in the UAT Strategy.
  • If you need to perform data migration, create and use the Data Migration Strategy document to mitigate specific risks related to data migration and pre-approve the document. Include data migration sources in the conversion strategy; this will make it difficult for the customer to communicate later there are other source systems;
  • Include data correction and coherence assumptions in the conversion strategy; this will ensure all parties are committed to giving clean data for conversion;
  • Include conversion procedure, including manual and semi-automatic procedure in the conversion strategy; this will mitigate the risk of unrealistic expectations that all data will be imported automatically;
  • Include migrated data tests and acceptance criteria in the conversion strategy (e.g. quantitative through counting in the database; qualitative through samples, visual inspection, formulas). This will mitigate unrealistic expectations that all migrated data can be tested for correctness.
  • Use the Training Strategy to propose a several layers of training that include readiness assessment, re-training sessions and workshops with end-users after go-live. For most projects, one initial training is not enough and end-users end up rejecting the system.
  • Perform initial orientation for own and customer team and have the materials ready to perform orientation whenever a new member arrives. This will mitigate Project Team not knowing where the project is heading, new members disrupting the direction of the project, or staff (including customer's) not understanding their role in the project.
  • Use Post-production Strategy to assign level 0 and level 1 support to key users, with clear responsibilities for the customer. This will avoid trivial issues or operating errors to get to the implementation team, saving your team's time for the real important issues;
  • Include a bug tracking system working procedure in the post-production strategy that states who should check for duplicates and trivial issues before they are assigned to the implementation team; also to avoid bugs arriving on different channels to the implementation team.
Happy Risk Management! and soon to come is part 3 - Closing.


Risk Management at the Source - Part 1: Initiating and Planning

Have you ever came across one of those Risk Management courses that endlessly talk about probabilities, impact, mitigation strategies and the process of assessing risks and putting them in a risk log? Although not a brainer, this approach on Risk Management transforms it in a academic exercise, which explains why in many projects RM is performed only when an audit is around the corner and you need some paperwork to prove you're doing an outstanding Project Management job.

When in fact, even without this paperwork, you are doing an outstanding Project Management job. Because most of our Project Management activities are about managing risks, maybe not as explicitly as if they were listed in a Risk Log. After acquiring some Project Management experience, most of us PMs learn some risks are more likely to happen then other, are able to foresee future problems from current symptoms, and conduct our PM activities mostly around mitigating and minimizing those risks.

So why not recognize this phenomena and create a new approach on Risk Management? A Risk Management that is in the center of Project Management activities, that is real, practical and common sense. Just like Quality at the Source is about embedding Quality at every step of the production, Risk Management is embedded in all project management activities. With this new approach, we want to see a Risk Management perspective on every activity a Project Manager does rather then having an isolated process called Risk Management. Just as in the project lifecycle, we propose:

  1. an Initiating and Planning phase with a Risk Management perspective
  2. a Monitoring and Controlling phase with a Risk Management perspective
  3. a Closing risks phase with a Risk Management perspective
(simplification as compared to the PMI project lifecycle is intentional).

I have listed below some techniques for embedding Risk Management in the Initiating and Planning activities. More posts will follow for Monitoring and Controlling and Closing. Again we talk IT (but most of our projects today touch IT so it became a familiar domain for most of us):

  • Delivery Method: If you include in your method tasks such as early prototyping, iterations and workshops with the client, you are already planning for mitigating risks such as heavy re-work in the late phases of the project or users not accepting your solution;
  • Constraints and Assumptions in the offer/contract/Project Management Plan.  Constraints and assumptions should refer to limits of what you can do and under which circumstances. These contain the knowledge of the past, of things you know can go wrong or misunderstandings that explode the budget. Have this list updated at the end of each project and don't name it "Lessons learnt" or in any other fancy terms; just a bullet list with assumptions and constraints to be added in the next proposal. List them on components, so you can easily extract what applies on the next project (e.g. hardware, communication, custom development, application implementation, data migration, Business Intelligence, training);
  • Kick-off presentation. Include in your kick-off presentation to the client a summary of the scope of work, including out-of-scope. This will address the risk of scope creep as the audience will be told early on what is and what is not in the scope of work.
  • Communication: Instead of presenting your list of risks to the client, throw a "Risk Assessment Workshop" together with your client. If you hear their concerns, it would be easier for your concerns to be heard.
  • Project Management Method: Include an Acceptance Methodology in the offer/contract/Project Management Plan that contains chapters for each deliverable type (e.g. different methodology for documents, application, data migration, training, hardware, networking services, etc). This of course will save you time and energy in the future if people have different expectancies regarding what acceptance is;
  • Include default acceptance that will allow you to handle non-responsive clients and move the project forward;
  • Plan for acceptance criteria that are not absolute in the case of software application. Software will never be bug-free and often it is more valuable to go-live with known issues rather then wait for the application to be perfect. You can phrase it like this: "The application will be considered accepted and ready for go-live if, following the UAT, there are no Severity 1 bugs, 4 or less Severity 2 bugs and there is an agreed plan, with deadlines, for solving all open bugs. ". Then list what Severity 1, 2 and 3 means. With this simple phrase you've just mitigated delays and negative cashflow risks;
  • Training and communication. Perform orientation and create an orientation communication package for the team, own and customer. This will address the Project Team not knowing where the project is heading or customer staff not understanding their role in the project;
  • Scope Management. Include a Change Control method in the offer/contract/Project Management Plan. We've discussed here that Change Control is not for rejecting change; still the absence of the mechanism invites to scope creep;
  • Project Governance. Establish the Project Governance structure, with layers and rules for reporting or escalating, explaining how risks will be brought up and escalated. This will address the risk of slow decision making, the risk of lack of resources and the risk of hurting the feelings of the people being escalated if they know from the beginning this mechanism with clear rules is in place (never underestimate the cost of hurt feelings :) );
  • Communication again, Staff Management. Explain to everyone in the team that you expect them to communicate any perceived risks and issues, including "Project Management risks and issues" such as scope creep. This ensures your team feels empowered to communicate and to give you hints you might miss;
  • Staff Management, Work Management. Create a staff plan for resources required from your client and hand it to them before the project starts. Include it in the offer/contract/Project Management Plan. This will address unrealistic expectations and lack of resources from the customer.
 I would be happy to hear from you whether Risk Management sounds less abstract now and more like common sense. Posts on Monitoring and Controlling and Closing will follow.


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.