Project Success vs Scope and Timeline Limitations

Sometimes we all have to deal with a fixed scope and timeline in our projects. The reasons for this are important business events, external deadlines that you can’t move, etc. In such circumstances it is also often impossible to significantly reduce the project scope.

This article gives advice on how to approach the planning and execution of a project with a fixed scope and timeline (further on: fixed project).

Planning

The following steps should be taken to plan a fixed project correctly:

• Fix the scope baseline on a level which allows the team to give an accurate estimate. In practice, this means that the project requirements should be documented on a user-story level (including user story acceptance criteria); the UI requirements should be agreed on at the UX-prototype level; and the design guidelines should be approved as well. All external APIs that your code depends upon should be well-documented. If at least one of these points can’t be fulfilled, a Project Manager should not make the commitment to deliver within a fixed timeline. It is better to outline existing unclarities and suggest a way to clarify them, or at least include them into the project risk registry.
•  Estimate the scope together with the team. There are many effort estimation methods that you can use, so choose the one that has already proven itself as an efficient one for your team. You can use either hours or story-points, keeping in mind your team’s focus-factor and velocity.
• Develop a release plan. At this stage you already have an effort estimate for the scope, but it is not enough to plan a project release. Now you have to create a plan which includes dependencies between the tasks and reflects the time required for regression testing and stabilization, user acceptance testing, production environment preparation and the release itself. You would need such a plan, even if you had an ideal continuous delivery pipeline and fully automated test coverage allowing you to deploy the code into the production environment multiple times per day, otherwise you wouldn’t take into account the time required to perform all the needed steps.
• Agree on the release plan with the team. The outcomes of the previous step should be discussed and agreed upon with the team before you make any commitments. That’s why a Project Manager should conduct a planning session with the team, present the plan and gather the team’s feedback, and then change the plan accordingly. This way you will achieve two goals at once, obtaining an accurate plan and making sure the team is confident about it. Techniques such as ‘confidence vote’ have proven to be very useful here too.
• Identify the risks and plan their mitigation. In other words, to create a risk registry (list), put all potential problems on it as well as the ways to solve or prevent them. Ideally you should be able to assess how each of the risks could impact the project timeline and scope. The best way to do that is to conduct a brainstorming session with the team and identify ‘what could go wrong’ and document the outcomes. This session could be combined with the planning session described above.
•  Create a deployment plan. A plan to rollout your product in a production environment and all other environments is required to complete the project (UAT, etc). At the release planning stage, the deployment plan could be a very high-level document outlining the resources required (servers, network access, etc) as well as who will be responsible for the deployment and who will participate in it. This is especially important if the deployment is performed by a specialized team (which happens often in enterprise-level organizations).
• Agree on the plan for user acceptance-testing (UAT). The plan should include a timeline, a way to collect user feedback, as well as defect severity levels to be fixed during the UAT phase and those that can be postponed. It is important to agree on the definition of the severity levels so that the development team and the client are aligned in their understanding. The plan should define the level and the number of defects enabling the start of the UAT.

The outcomes of the above steps should be documented and agreed upon between the service provider and the client; this is a mandatory and a very important step.

To be able to commit to a fixed timeline and scope you can’t skip any of these points, otherwise you will form unrealistic expectations.

Taking a fixed commitment for a release longer than 3 months is generally a bad idea as almost always the project becomes too risky. If the scope requires more time to deliver, divide it into smaller parts and commit to the first part only.

Execution and Reporting

Once planning is finalized and the plan is agreed on by the team and the client, it is time to start with project execution. You can execute the plan iteratively using the same approach you would use for an agile project. You will need to collect the client’s feedback which will result in some scope changes (despite the scope being fixed). While the next section describes the change in the management approach in detail, this one covers the main Project Manager’s tasks during the project execution stage.

They include:

• Removing all issues and impediments in the team’s way (this process is, most likely, the most time-consuming)
• Project execution monitoring and modification
• Reporting and communication with main stakeholders

Let’s discuss the two latter points in detail.

Project execution monitoring. The key point for a Project Manager here is to have a tool that allows you to quickly identify how much of a percent of the agreed scope has been implemented and how much has not, and whether you are moving according to the schedule. The simplest way to do this is to assume that your team will deliver the scope linearly; meaning that approximately the same portion of the scope is delivered each day. This assumption is very close to the truth, especially on a large scale. Based on this assumption, the planned percentage of the scope on a particular day of the project can be calculated as team daily velocity multiplied by the number of the days passed from the project start. The actual percentage in turn can be calculated by dividing the total estimof all closed tasks by the total project estimate. As a result you obtain two numbers: the planned and actual progress of the project. Now you can identify if you are on track by comparing them.

It is important to remember that such an approach works during the development phase only; when the team develops and tests the features iteratively. This approach can’t be directly applied to the other phases of the project, such as regression, stabilization, UAT, etc. Moreover, if team velocity changes over time (let’s say you increase the team in the middle of the project) you will need to use a more generic method, such as the earned value method, described in detail in PMBoK.

Once you understand what your actual progress is you may need to correct your plan for various reasons, like scope changes, activated risks, etc. Once you correct the plan, you can update the forecast of the estimated delivery date.

Reporting and communicating with the stakeholders is one of the most important tasks of a Project Manager. The main goal here is to keep your stakeholders (the client, company management, etc) informed about the project progress, identified issues and impediments, and how they can help you to resolve them.

Typical project reports must include the following information:

• Actual and planned progress to date
• The list of current issues and the ways to solve them (here you also describe how the stakeholders can help you)
• An update on risks and their current probability and status (some of them have been activated, while some are already solved and can be closed)
• A brief description of current team activities (this point is optional)

The reports must be sent on a weekly or bi-weekly basis. The shorter your release timeline is the more frequent your communication should be. In addition to the reports shared by email, it may be useful to schedule a recurring status meeting with all main stakeholders, in order to go through the report and discuss the current progress and impediments in more detail.

AFE: Digital Transformation with speed and scale

Scope change management

So, you have started your project, and you are moving according to the schedule, delivering a small part of the scope every day while solving issues and impediments arising along the way. Even with a short project, you need to collect and process the client’s feedback, so you should conduct weekly (or bi-weekly) demos to show the client the interim outcomes of the project. During these demos the clients will give you feedback and may initiate some changes to the scope. Even in a fixed scope project, changes are inevitable and the client has the right to request them. With this right, the client undertakes the responsibility to decide whether they want to postpone the release date due to the introduction of the changes or to keep the delivery date intact and postpone the scope changes. The Project Manager’s responsibility is to let the client know how the suggested changes impact the release date.

The following approach has proven itself as a reliable one.

Every change request is documented in a change registry and is analyzed by the team (especially by the business analyst) in order to determine whether it is within the initially agreed scope or is actually a change. If it’s a part of the initial scope, it is the team’s responsibility to deliver it within the initially agreed upon timeline. If not, the team should estimate the impact on the release date and inform the client about it. Now the client has to decide whether to approve the change and postpone the release date, or maybe to remove some other feature from the scope so as to free up the scope for the new change.

A good practice is to conduct periodical meetings with the client to discuss every change request, it’s potential impact on the release date, and to agree upon the next steps.

→ How to choose an outsourcing service provider

It is important to maintain a change registry and ensure it is always up-to-date so that you can consistently analyze the cumulative impact of all approved changes on the release date. Also, it is important to remember that changes impact not only the upcoming functionality but also features that have been already delivered.

User acceptance testing

Now that you have delivered all the requested features, performed regression testing and stabilization of the solution, you need to ensure the solution addresses the client’s business goals and obtain the client’s approval to go to production.

While you have obtained the client’s interim feedback during your sprint demos, it is important now to ensure the solution works and realistically addresses the business requirements as a whole. The client should try the solution in different cases so as to verify whether all the business aspects were taken into account while specifying the requirements for the project.

→ Read more about Avenga quality management services

Therefore the User Acceptance Testing (UAT) is conducted to:

• Ensure the initially agreed upon requirements correspond to the client’s needs.
• Identify the defects that your QA team could not identify before (your clients know their business much better than you and can try the cases you didn’t even think of).
• Get the ‘go’ decision to deploy the system to production, or to postpone the release to add some more features to the release candidate.

Actually during the UAT phase, the client does not test the system (it is the QA team’s job) but tests the requirements the system was developed according to.

An effective way to conduct a UAT is:

• The team, together with the client, creates user acceptance scenarios. They reflect both very typical and very rare cases. Some of the cases are marked as mandatory, meaning that the system can only be accepted if these cases work correctly.
• The client executes the scenarios using the test instance of the system and marks each scenario as “accepted” or “rejected”. In the latter case, the client describes the reason for rejecting the scenario or registers a defect in a defect-tracking tool (e.g., Jira).
• The team analyzes the defects and discusses them with the client in order to decide what defects have to be fixed before the release and which of them can be postponed.

At the end of the UAT the client makes a final decision, whether to go live with the current release candidate or to postpone the release to make more changes.

Production release and post-release support

The system deployment plan preliminarily agreed upon before the start of the project should now be described in more detail and re-approved. Normally it contains the following information:

• Technical steps needed to deploy the system – which servers are used, what is the sequence of system components deployment, etc.
• Organizational details – who makes the final ‘go’ decision, what personnel conduct the deployment activities, at what time the activities begin and end, and what downtime is considered acceptable.
• Rollback-plan – (probably the most important part of the deployment plan) what to do if something goes wrong, how to restore a previous version of the system, etc.

The deployment plan should be approved by the client, by both technical and business representatives. A dry run of the deployment is performed in one of the test environments to ensure all the details have been included.

Right after the release, the team may get urgent requests from the client and apply hotfixes if required; even after a thorough testing some defects can be only identified in the production environment.

It is recommended that after the release the client quickly goes through the system and confirms that everything is working as expected.

Whatever your project needs are, it’s always about well-thought strategy, skillful implementation and attention to details which makes every idea a success.

→ Read about how we at Avenga evaluate, benchmark, manage, and increase your business value.