To Know
-
Out with the old, in with the new
A Delivery Framework for Software Re-Engineering Projects
CALL To Life
—
Dec 2019
In a perfect world, when a solution needs to be replaced, it contains all the documentation needed to understand its current behaviour, how it is built and how to access it. Of course, in practice, this is seldom the case, and consequently makes these types of projects high risk.
Nowadays, one of the issues that every company faces within its organisation is the lack of know-how in certain systems or at least the lack of information or documentation about those certain systems. This happens mostly in big organisations, with several years of presence in the market where their infrastructure is considerably complex and sometimes old.
Replacing a system that works properly, has low maintenance costs, is considered a risky move for most of the company management’s departments and therefore are usually not keen on doing it. On the management point of view, adding unnecessary risk, is not worth it and that’s why these kinds of decisions are usually postponed repeatedly. However, systems do get old and obsolete and companies are forced to evolve their systems, sooner or later. At that time, organisations which are forced to change their legacy systems can either, renew their support with the current vendor and add some improvements, if needed, or ask someone else to build a new system with the same capabilities (or more), in a brand new and trendy technology.
The delivery framework methodology for reengineering projects aims to help future migration projects to be efficient and achieve desirable success. Users shall use this framework as a receipt to successfully migrate their black boxes into new, well documented, and under controlled target systems.
Of course, the usage of the framework may need some adaptations depending on the customer you are facing. Its professional experience, culture or personality may lead you to react to unexpected circumstances, and you’ll need to adapt accordingly. Nevertheless, the Delivery Framework for Reengineering projects was built to cover as many areas as possible, regarding delivering migration projects. The main goal is to define standards and guidelines so the processes of our companies can be more efficient. Both the customers and vendors will have benefits on that, saving money, time and improving the quality of the systems implemented.
The Delivery Framework includes the following workstreams/main processes:
For each activity of the different processes, there will be always 4 questions to be answered and a defined target audience. Here’s a brief explanation on this:
The first step, to successfully run a project, is to set it up and prepare it as well as possible. So, the starting point will be the setup process. Considering previous experiences, we noticed that it’s been difficult to engage all the stakeholders in the project, that risks were badly managed, and no correct methodologies were used in terms of the E2E delivery of the project. All these problems won’t happen, if the setup and preparation of a project, are well performed. Let’s see the guideline to correctly set up a migration project.
The purpose of this first process is to build the process which will be used throughout the project and engage all the relevant stakeholders on it. Everyone will have a role within the project, make them understand the importance of their role, as well as the expected value of their contribution to the project. Communication is key to run a successful project. Indications on how they should communicate, when and which are the inputs and outputs they shall share, are some of the topics which need to be addressed at this stage.
After executing all these processes, we reach the end of the Setup phase. But, while sharing the Project Governance document with all these outputs, it’s important to explain to all stakeholders, how the project will be conducted, and how the project management process will benefit everyone involved in the project.
The project management process is a continuous process executed iteratively throughout the whole project. It has 3 main stages, represented by the 3 meetings in the diagram above. The first of them is internal and shall include all the internal stakeholders of the project. Here, the project manager looks to the project calendar, and identifies the task of the week and allocate them to the resources available. It’s conducted the same way has a weekly status with the customer, but with 100% transparency. The team shall share all the concerns, problems and risks of the tasks identified. The project manager tracks the progress and completeness of the activities to share later with the external stakeholders of the project. After assessing how our team is progressing, we can track the overall state of the project, running the weekly status meeting with all the project stakeholders.
For the engagement of other teams, and to make sure all the mandatory stakeholders attend the meeting, the communication model needs to get into the action. During the project and, depending on the work-streams we are working on, the communication model shall be updated. If so, a meeting shall be scheduled with the new mandatory attendees and communicate to them their responsibilities during the next activities and engaged them with the process.
At this stage, every stakeholder shall know its role in the project, which meeting must attend, which activities are his/her responsibility, when they need to be executed and where and how the outputs shall be shared. If that’s not the case, run the project setup process again, until this is clear.
A successful setup phase is essential to kick off the project towards the right path, but the assessment of the legacy system, the main topic which this Delivery Framework intends to address, that’s the phase where the hardest challenges appear. The other half is assessing the requirements of the legacy systems correctly, which is intended to migrate during the project. Note that, although the focus of the Delivery Framework is to build a set of processes to migrate black boxes to new systems, this framework can also be used for green fields, and if that’s the case, this phase shall be skipped.
This is a very important stage during a migration project. Both Vendor and Customers shall put a lot of effort in order to get as many requirements as possible, from the legacy system. We all know the tree swing cartoon, and what happens when the requirements are not well defined. Therefore, this delivery framework will define a guideline containing the activities and processes the project team can execute, in order to get the requirements from the legacy system.
All the questions above will help the Project Team understand the legacy system’s behaviour, both functional and technical. The importance of this assessment process is covering as much of the legacy system’s universe as possible. Consequently, less unexpected requirements or demands will show up in a later stage.
No matter if we are migrating a legacy system, or implementing a greenfield project, from now on, the framework shall be used in the same way for both scenarios. For a migration process, the number of challenges will vary based on how successful the setup and assessment phases were, whereas a greenfield project just depends on the setup Workstream. We may argue that even for a greenfield, requirements may not be clear, but the assessment activities won’t help us improve that aspect. Regardless of the clarity of the initial requirements or the assessment outputs, it’s during this stage of the project that the scope will be close, and therefore, an important process to execute during the project.
Thus, the first question we should make ourselves is exactly related to scope. Is it beneficial for us (Vendor), run a delivery project based on a scope? Or shall it run based on time?
The Delivery Work-stream of the framework will be used for the two main components of a migration project: Software Development and Professional Services. In some projects, only one of the 2 processes might be used. For instance, if you are deploying a major release of a product, you may apply only Product Delivery process, whereas if you are running a project with Professional Services' activities only, you shall use the Project Delivery process only (e.g.: Building a new site for scalability purposes). As said, each one of the processes will have 5 stages. They are: Design, Build, Validation, Training and Deploy.
Regardless of using Agile or Waterfall methodologies, the process flow will be the same. If you use a waterfall approach, you will execute the whole flow once, whereas in a more iterative approach you will use it several times. Here’s the high-level view of the Delivery process:
Now, for a migration project, as mentioned before, we will have both Product Delivery and Project Delivery streams. The following diagram shows the dependencies. These dependencies are identified in the setup phase of the project and tracked throughout the project by the Project Manager.
When the project starts, during the design of the product, new system requirements may appear. A product requirement can originate a new system interface, a new 3rd party software installed on the system, and many others. Therefore, the Project Design depends on Product Design. The next identified dependency is between Product Validation and the Project Build. After both Product and Project Design being concluded, both the Product and Project Build may proceed. Once concluded and to advance to the Product Validation, it is required to have the LAB environments ready, and therefore the Project Validation process depends on the conclusion of the Project Build.
For the Training stream, the flow is simple. The Development Team coaches the Project Team, and the Project Team merges that knowledge with the activities done on the Project stream and coaches the Customer teams in the Project Training Stream. For the Validation stream, in order to segregate risk, and make the troubleshooting easier, the Product Validation is immediately followed by the Project Validation. Which means that, after the product being accepted, and all the functional requirements are met, the non-functional requirements are validated.
In the end, the product is deployed in Live, once the Live environment is ready, and therefore the roles change, and at this time, the Product Delivery stream depends on the Project Delivery. The Project Deployment stage shall be concluded before the Product Go Live, once again, to segregate risk between both processes. If they are executed at the same time, and the application doesn’t work, there can be a lot of reasons where the problem can be, and as much time we take to find a problem, the more expensive will be the fix. As mentioned before, once concluded the Delivery stream, the service migrations can start. Before executing the service migrations, it’s necessary to execute the Migration Process of the delivery framework.
The migration process will include 4 activities: Assessing the legacy system, Map the legacy system with the new target system, Development and Acceptance, as the picture below show. To start this process the assessment phase shall be concluded, as well as the Product Design. In fact, the migration process shall be triggered as late as possible, for one main reason. The later the migration process is triggered, the lower is the probability of new designs being requested, and consequently the lower the probability of redesigning the migration tool. Of course, too much later, would mean delays in the service migration which is not desirable, as well. Therefore, the Project Manager needs to find the right balance to avoid delays on the migration tool development, but at the same time, avoid late change requests to the product design. Here’s the high-level view of the migration process:
Once the project is concluded, it’s time for the project closure, and to implement the last process of the Delivery Framework.
After all the efforts to successfully conduct the project towards its end, it’s important to receive feedback from all those involved. In the Lessons Learned session, all the stakeholders shall share the positive and less positive aspects of the project. For the less positive ones, it’s always beneficial to have an action plan, or a reflection on how to avoid those aspects, in the future projects.
Article by Rui Pereira – Unified Communications
Rui completed his master’s degree with this thesis on A Delivery Framework for Software Re-Engineering Projects. He is currently implementing this research within the new mCAS Deployment for Vodafone UK, a project that aims to upgrade the current software platform and deliver two new platforms to distribute existing applications in order to segregate risk by having the Enterprise and Consumer market in different platforms.
In a perfect world, when a solution needs to be replaced, it contains all the documentation needed to understand its current behaviour, how it is built and how to access it. Of course, in practice, this is seldom the case, and consequently makes these types of projects high risk.
Nowadays, one of the issues that every company faces within its organisation is the lack of know-how in certain systems or at least the lack of information or documentation about those certain systems. This happens mostly in big organisations, with several years of presence in the market where their infrastructure is considerably complex and sometimes old.
Replacing a system that works properly, has low maintenance costs, is considered a risky move for most of the company management’s departments and therefore are usually not keen on doing it. On the management point of view, adding unnecessary risk, is not worth it and that’s why these kinds of decisions are usually postponed repeatedly. However, systems do get old and obsolete and companies are forced to evolve their systems, sooner or later. At that time, organisations which are forced to change their legacy systems can either, renew their support with the current vendor and add some improvements, if needed, or ask someone else to build a new system with the same capabilities (or more), in a brand new and trendy technology.
The delivery framework methodology for reengineering projects aims to help future migration projects to be efficient and achieve desirable success. Users shall use this framework as a receipt to successfully migrate their black boxes into new, well documented, and under controlled target systems.
Of course, the usage of the framework may need some adaptations depending on the customer you are facing. Its professional experience, culture or personality may lead you to react to unexpected circumstances, and you’ll need to adapt accordingly. Nevertheless, the Delivery Framework for Reengineering projects was built to cover as many areas as possible, regarding delivering migration projects. The main goal is to define standards and guidelines so the processes of our companies can be more efficient. Both the customers and vendors will have benefits on that, saving money, time and improving the quality of the systems implemented.
The Delivery Framework includes the following workstreams/main processes:
For each activity of the different processes, there will be always 4 questions to be answered and a defined target audience. Here’s a brief explanation on this:
The first step, to successfully run a project, is to set it up and prepare it as well as possible. So, the starting point will be the setup process. Considering previous experiences, we noticed that it’s been difficult to engage all the stakeholders in the project, that risks were badly managed, and no correct methodologies were used in terms of the E2E delivery of the project. All these problems won’t happen, if the setup and preparation of a project, are well performed. Let’s see the guideline to correctly set up a migration project.
The purpose of this first process is to build the process which will be used throughout the project and engage all the relevant stakeholders on it. Everyone will have a role within the project, make them understand the importance of their role, as well as the expected value of their contribution to the project. Communication is key to run a successful project. Indications on how they should communicate, when and which are the inputs and outputs they shall share, are some of the topics which need to be addressed at this stage.
After executing all these processes, we reach the end of the Setup phase. But, while sharing the Project Governance document with all these outputs, it’s important to explain to all stakeholders, how the project will be conducted, and how the project management process will benefit everyone involved in the project.
The project management process is a continuous process executed iteratively throughout the whole project. It has 3 main stages, represented by the 3 meetings in the diagram above. The first of them is internal and shall include all the internal stakeholders of the project. Here, the project manager looks to the project calendar, and identifies the task of the week and allocate them to the resources available. It’s conducted the same way has a weekly status with the customer, but with 100% transparency. The team shall share all the concerns, problems and risks of the tasks identified. The project manager tracks the progress and completeness of the activities to share later with the external stakeholders of the project. After assessing how our team is progressing, we can track the overall state of the project, running the weekly status meeting with all the project stakeholders.
For the engagement of other teams, and to make sure all the mandatory stakeholders attend the meeting, the communication model needs to get into the action. During the project and, depending on the work-streams we are working on, the communication model shall be updated. If so, a meeting shall be scheduled with the new mandatory attendees and communicate to them their responsibilities during the next activities and engaged them with the process.
At this stage, every stakeholder shall know its role in the project, which meeting must attend, which activities are his/her responsibility, when they need to be executed and where and how the outputs shall be shared. If that’s not the case, run the project setup process again, until this is clear.
A successful setup phase is essential to kick off the project towards the right path, but the assessment of the legacy system, the main topic which this Delivery Framework intends to address, that’s the phase where the hardest challenges appear. The other half is assessing the requirements of the legacy systems correctly, which is intended to migrate during the project. Note that, although the focus of the Delivery Framework is to build a set of processes to migrate black boxes to new systems, this framework can also be used for green fields, and if that’s the case, this phase shall be skipped.
This is a very important stage during a migration project. Both Vendor and Customers shall put a lot of effort in order to get as many requirements as possible, from the legacy system. We all know the tree swing cartoon, and what happens when the requirements are not well defined. Therefore, this delivery framework will define a guideline containing the activities and processes the project team can execute, in order to get the requirements from the legacy system.
All the questions above will help the Project Team understand the legacy system’s behaviour, both functional and technical. The importance of this assessment process is covering as much of the legacy system’s universe as possible. Consequently, less unexpected requirements or demands will show up in a later stage.
No matter if we are migrating a legacy system, or implementing a greenfield project, from now on, the framework shall be used in the same way for both scenarios. For a migration process, the number of challenges will vary based on how successful the setup and assessment phases were, whereas a greenfield project just depends on the setup Workstream. We may argue that even for a greenfield, requirements may not be clear, but the assessment activities won’t help us improve that aspect. Regardless of the clarity of the initial requirements or the assessment outputs, it’s during this stage of the project that the scope will be close, and therefore, an important process to execute during the project.
Thus, the first question we should make ourselves is exactly related to scope. Is it beneficial for us (Vendor), run a delivery project based on a scope? Or shall it run based on time?
The Delivery Work-stream of the framework will be used for the two main components of a migration project: Software Development and Professional Services. In some projects, only one of the 2 processes might be used. For instance, if you are deploying a major release of a product, you may apply only Product Delivery process, whereas if you are running a project with Professional Services' activities only, you shall use the Project Delivery process only (e.g.: Building a new site for scalability purposes). As said, each one of the processes will have 5 stages. They are: Design, Build, Validation, Training and Deploy.
Regardless of using Agile or Waterfall methodologies, the process flow will be the same. If you use a waterfall approach, you will execute the whole flow once, whereas in a more iterative approach you will use it several times. Here’s the high-level view of the Delivery process:
Now, for a migration project, as mentioned before, we will have both Product Delivery and Project Delivery streams. The following diagram shows the dependencies. These dependencies are identified in the setup phase of the project and tracked throughout the project by the Project Manager.
When the project starts, during the design of the product, new system requirements may appear. A product requirement can originate a new system interface, a new 3rd party software installed on the system, and many others. Therefore, the Project Design depends on Product Design. The next identified dependency is between Product Validation and the Project Build. After both Product and Project Design being concluded, both the Product and Project Build may proceed. Once concluded and to advance to the Product Validation, it is required to have the LAB environments ready, and therefore the Project Validation process depends on the conclusion of the Project Build.
For the Training stream, the flow is simple. The Development Team coaches the Project Team, and the Project Team merges that knowledge with the activities done on the Project stream and coaches the Customer teams in the Project Training Stream. For the Validation stream, in order to segregate risk, and make the troubleshooting easier, the Product Validation is immediately followed by the Project Validation. Which means that, after the product being accepted, and all the functional requirements are met, the non-functional requirements are validated.
In the end, the product is deployed in Live, once the Live environment is ready, and therefore the roles change, and at this time, the Product Delivery stream depends on the Project Delivery. The Project Deployment stage shall be concluded before the Product Go Live, once again, to segregate risk between both processes. If they are executed at the same time, and the application doesn’t work, there can be a lot of reasons where the problem can be, and as much time we take to find a problem, the more expensive will be the fix. As mentioned before, once concluded the Delivery stream, the service migrations can start. Before executing the service migrations, it’s necessary to execute the Migration Process of the delivery framework.
The migration process will include 4 activities: Assessing the legacy system, Map the legacy system with the new target system, Development and Acceptance, as the picture below show. To start this process the assessment phase shall be concluded, as well as the Product Design. In fact, the migration process shall be triggered as late as possible, for one main reason. The later the migration process is triggered, the lower is the probability of new designs being requested, and consequently the lower the probability of redesigning the migration tool. Of course, too much later, would mean delays in the service migration which is not desirable, as well. Therefore, the Project Manager needs to find the right balance to avoid delays on the migration tool development, but at the same time, avoid late change requests to the product design. Here’s the high-level view of the migration process:
Once the project is concluded, it’s time for the project closure, and to implement the last process of the Delivery Framework.
After all the efforts to successfully conduct the project towards its end, it’s important to receive feedback from all those involved. In the Lessons Learned session, all the stakeholders shall share the positive and less positive aspects of the project. For the less positive ones, it’s always beneficial to have an action plan, or a reflection on how to avoid those aspects, in the future projects.
Article by Rui Pereira – Unified Communications
Rui completed his master’s degree with this thesis on A Delivery Framework for Software Re-Engineering Projects. He is currently implementing this research within the new mCAS Deployment for Vodafone UK, a project that aims to upgrade the current software platform and deliver two new platforms to distribute existing applications in order to segregate risk by having the Enterprise and Consumer market in different platforms.
In a perfect world, when a solution needs to be replaced, it contains all the documentation needed to understand its current behaviour, how it is built and how to access it. Of course, in practice, this is seldom the case, and consequently makes these types of projects high risk.
Nowadays, one of the issues that every company faces within its organisation is the lack of know-how in certain systems or at least the lack of information or documentation about those certain systems. This happens mostly in big organisations, with several years of presence in the market where their infrastructure is considerably complex and sometimes old.
Replacing a system that works properly, has low maintenance costs, is considered a risky move for most of the company management’s departments and therefore are usually not keen on doing it. On the management point of view, adding unnecessary risk, is not worth it and that’s why these kinds of decisions are usually postponed repeatedly. However, systems do get old and obsolete and companies are forced to evolve their systems, sooner or later. At that time, organisations which are forced to change their legacy systems can either, renew their support with the current vendor and add some improvements, if needed, or ask someone else to build a new system with the same capabilities (or more), in a brand new and trendy technology.
The delivery framework methodology for reengineering projects aims to help future migration projects to be efficient and achieve desirable success. Users shall use this framework as a receipt to successfully migrate their black boxes into new, well documented, and under controlled target systems.
Of course, the usage of the framework may need some adaptations depending on the customer you are facing. Its professional experience, culture or personality may lead you to react to unexpected circumstances, and you’ll need to adapt accordingly. Nevertheless, the Delivery Framework for Reengineering projects was built to cover as many areas as possible, regarding delivering migration projects. The main goal is to define standards and guidelines so the processes of our companies can be more efficient. Both the customers and vendors will have benefits on that, saving money, time and improving the quality of the systems implemented.
The Delivery Framework includes the following workstreams/main processes:
For each activity of the different processes, there will be always 4 questions to be answered and a defined target audience. Here’s a brief explanation on this:
The first step, to successfully run a project, is to set it up and prepare it as well as possible. So, the starting point will be the setup process. Considering previous experiences, we noticed that it’s been difficult to engage all the stakeholders in the project, that risks were badly managed, and no correct methodologies were used in terms of the E2E delivery of the project. All these problems won’t happen, if the setup and preparation of a project, are well performed. Let’s see the guideline to correctly set up a migration project.
The purpose of this first process is to build the process which will be used throughout the project and engage all the relevant stakeholders on it. Everyone will have a role within the project, make them understand the importance of their role, as well as the expected value of their contribution to the project. Communication is key to run a successful project. Indications on how they should communicate, when and which are the inputs and outputs they shall share, are some of the topics which need to be addressed at this stage.
After executing all these processes, we reach the end of the Setup phase. But, while sharing the Project Governance document with all these outputs, it’s important to explain to all stakeholders, how the project will be conducted, and how the project management process will benefit everyone involved in the project.
The project management process is a continuous process executed iteratively throughout the whole project. It has 3 main stages, represented by the 3 meetings in the diagram above. The first of them is internal and shall include all the internal stakeholders of the project. Here, the project manager looks to the project calendar, and identifies the task of the week and allocate them to the resources available. It’s conducted the same way has a weekly status with the customer, but with 100% transparency. The team shall share all the concerns, problems and risks of the tasks identified. The project manager tracks the progress and completeness of the activities to share later with the external stakeholders of the project. After assessing how our team is progressing, we can track the overall state of the project, running the weekly status meeting with all the project stakeholders.
For the engagement of other teams, and to make sure all the mandatory stakeholders attend the meeting, the communication model needs to get into the action. During the project and, depending on the work-streams we are working on, the communication model shall be updated. If so, a meeting shall be scheduled with the new mandatory attendees and communicate to them their responsibilities during the next activities and engaged them with the process.
At this stage, every stakeholder shall know its role in the project, which meeting must attend, which activities are his/her responsibility, when they need to be executed and where and how the outputs shall be shared. If that’s not the case, run the project setup process again, until this is clear.
A successful setup phase is essential to kick off the project towards the right path, but the assessment of the legacy system, the main topic which this Delivery Framework intends to address, that’s the phase where the hardest challenges appear. The other half is assessing the requirements of the legacy systems correctly, which is intended to migrate during the project. Note that, although the focus of the Delivery Framework is to build a set of processes to migrate black boxes to new systems, this framework can also be used for green fields, and if that’s the case, this phase shall be skipped.
This is a very important stage during a migration project. Both Vendor and Customers shall put a lot of effort in order to get as many requirements as possible, from the legacy system. We all know the tree swing cartoon, and what happens when the requirements are not well defined. Therefore, this delivery framework will define a guideline containing the activities and processes the project team can execute, in order to get the requirements from the legacy system.
All the questions above will help the Project Team understand the legacy system’s behaviour, both functional and technical. The importance of this assessment process is covering as much of the legacy system’s universe as possible. Consequently, less unexpected requirements or demands will show up in a later stage.
No matter if we are migrating a legacy system, or implementing a greenfield project, from now on, the framework shall be used in the same way for both scenarios. For a migration process, the number of challenges will vary based on how successful the setup and assessment phases were, whereas a greenfield project just depends on the setup Workstream. We may argue that even for a greenfield, requirements may not be clear, but the assessment activities won’t help us improve that aspect. Regardless of the clarity of the initial requirements or the assessment outputs, it’s during this stage of the project that the scope will be close, and therefore, an important process to execute during the project.
Thus, the first question we should make ourselves is exactly related to scope. Is it beneficial for us (Vendor), run a delivery project based on a scope? Or shall it run based on time?
The Delivery Work-stream of the framework will be used for the two main components of a migration project: Software Development and Professional Services. In some projects, only one of the 2 processes might be used. For instance, if you are deploying a major release of a product, you may apply only Product Delivery process, whereas if you are running a project with Professional Services' activities only, you shall use the Project Delivery process only (e.g.: Building a new site for scalability purposes). As said, each one of the processes will have 5 stages. They are: Design, Build, Validation, Training and Deploy.
Regardless of using Agile or Waterfall methodologies, the process flow will be the same. If you use a waterfall approach, you will execute the whole flow once, whereas in a more iterative approach you will use it several times. Here’s the high-level view of the Delivery process:
Now, for a migration project, as mentioned before, we will have both Product Delivery and Project Delivery streams. The following diagram shows the dependencies. These dependencies are identified in the setup phase of the project and tracked throughout the project by the Project Manager.
When the project starts, during the design of the product, new system requirements may appear. A product requirement can originate a new system interface, a new 3rd party software installed on the system, and many others. Therefore, the Project Design depends on Product Design. The next identified dependency is between Product Validation and the Project Build. After both Product and Project Design being concluded, both the Product and Project Build may proceed. Once concluded and to advance to the Product Validation, it is required to have the LAB environments ready, and therefore the Project Validation process depends on the conclusion of the Project Build.
For the Training stream, the flow is simple. The Development Team coaches the Project Team, and the Project Team merges that knowledge with the activities done on the Project stream and coaches the Customer teams in the Project Training Stream. For the Validation stream, in order to segregate risk, and make the troubleshooting easier, the Product Validation is immediately followed by the Project Validation. Which means that, after the product being accepted, and all the functional requirements are met, the non-functional requirements are validated.
In the end, the product is deployed in Live, once the Live environment is ready, and therefore the roles change, and at this time, the Product Delivery stream depends on the Project Delivery. The Project Deployment stage shall be concluded before the Product Go Live, once again, to segregate risk between both processes. If they are executed at the same time, and the application doesn’t work, there can be a lot of reasons where the problem can be, and as much time we take to find a problem, the more expensive will be the fix. As mentioned before, once concluded the Delivery stream, the service migrations can start. Before executing the service migrations, it’s necessary to execute the Migration Process of the delivery framework.
The migration process will include 4 activities: Assessing the legacy system, Map the legacy system with the new target system, Development and Acceptance, as the picture below show. To start this process the assessment phase shall be concluded, as well as the Product Design. In fact, the migration process shall be triggered as late as possible, for one main reason. The later the migration process is triggered, the lower is the probability of new designs being requested, and consequently the lower the probability of redesigning the migration tool. Of course, too much later, would mean delays in the service migration which is not desirable, as well. Therefore, the Project Manager needs to find the right balance to avoid delays on the migration tool development, but at the same time, avoid late change requests to the product design. Here’s the high-level view of the migration process:
Once the project is concluded, it’s time for the project closure, and to implement the last process of the Delivery Framework.
After all the efforts to successfully conduct the project towards its end, it’s important to receive feedback from all those involved. In the Lessons Learned session, all the stakeholders shall share the positive and less positive aspects of the project. For the less positive ones, it’s always beneficial to have an action plan, or a reflection on how to avoid those aspects, in the future projects.
Article by Rui Pereira – Unified Communications
Rui completed his master’s degree with this thesis on A Delivery Framework for Software Re-Engineering Projects. He is currently implementing this research within the new mCAS Deployment for Vodafone UK, a project that aims to upgrade the current software platform and deliver two new platforms to distribute existing applications in order to segregate risk by having the Enterprise and Consumer market in different platforms.
.png)
