Avenga’s response to the war on Ukraine: Business Continuity and Humanitarian Aid
Head of Presale in US
Table of content
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).
The following steps should be taken to plan a fixed project correctly:
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 month 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.
→ Daily project work prioritization: focus on real business value
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.
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:
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.
→ SAFE: Digital Transformation with speed and scale
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.
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:
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:
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.
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:
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.