Project considerations for artwork improvement programmes

Project considerations for artwork improvement programmes

In my first two articles in this series on change and programme management of artwork improvement projects, I talked about some of the issues that need to be considered when setting up an artwork capability improvement programme and some of the change management aspects to consider to ensure the change is delivered in a sustainable way.  In this article, I will look at the design of individual improvement projects to ensure effective delivery.

 

The basic structure of the project is likely to be relatively familiar to you and consists of five phases:

 

Project PhaseEnd milestone(s)
Concept developmentSituation & Strategy Development Approval
Situation & Strategy DesignProject Approval
Detailed Design, Build & TestDesign ApprovalGo/No-Go Implementation
ImplementationGo/No-Go Go-LiveApprove Project Close

 

The concept development phase has a number of key objectives:

 

  • Get buy-in from key senior management that there is an issue that needs to be investigated.
  • Form an initial steering team to govern the project.
  • Design the situation and strategy phase of the project.
  • Identify the resources required for the situation and strategy phase.
  • Gain formal approval for the situation and strategy phase.

 

During this initiation phase of the project there is always a significant dilemma to manage. On the one hand, there is no project approved at this point, so there is no significant budget available and there are almost certainly only a very small number of part-time resources available to work on the project. On the other hand, management will always want a fully developed case for action and project design before moving forward. This latter desire cannot realistically be met until the end of the next phase of the project and usually requires a relatively significant amount of effort.

 

The situation and strategy phase is the time to develop the compelling reason for action, thoroughly understand the as-is situation and define a to-be at a high level. This needs to be done with the involvement and buy-in of the main impacted functions in the organisation, of which the steering team members are a key element. Having got the as-is and to-be, the gap between the two will be clear and the project can be designed, resources identified and cost estimates developed. If there are key suppliers to be selected, then this process should begin here. It may be advantageous or even necessary to complete the selection process in this phase for some or all of the key suppliers. This phase culminates in the approval of the resources and funds for the rest of the project and is therefore the critical project approval point.

 

The design phase of the project is concerned with collaboratively developing the to-be in more detail and also designing in detail all aspects of the remaining phases of the project. At the end of this phase, there should be a clearly developed to-be design, at a level of detail that all parties can understand and has been tested for robustness.

 

As an example, this design would typically include:

 

  • process flow maps
  • roles and responsibility tables
  • information technology user requirements and initial functional requirements.

 

If there are key suppliers that need to be selected, then they will probably have been selected by the end of this phase and involved in the design. You will note that this design does not include writing standard operating procedures, education and training materials, or developing the detailed design of information technology systems. This phase would normally culminate in a formal approval of the to-be design by the steering team and any other key senior stakeholders who may be appropriate.

 

As the name suggests, the detailed design, build and test phase is the section of the project where the detailed design of the solution is completed, capabilities are built and tested. This will include items such as writing and approving standard operating procedures and education and training materials. Information technology systems and tools will also be designed, built and tested. It must be remembered that in a GxP and validated environment, the development and execution of the system testing is a significant endeavour in its own right, requiring significant quantities of resource and time to achieve.

 

Some time towards the end of this phase, a formal decision would normally be made that the design and tools are sufficiently well developed that the implementation phase can begin. The reason for this formal decision point is that the beginning of the implementation phase normally commits all impacted stakeholders to a significant amount of effort in preparation for “go-live” and therefore should only be commenced if the project is truly ready.

 

In our experience, many projects are delayed, or even fail, because managers underestimate the resources and time required to complete this phase adequately. This is often caused by too much optimism or bowing to pressure to cut timescales and cost in the situation and strategy phase. Ensuring some experienced, sufficiently senior views are brought to bear on plans in these early stages can help avoid this situation occurring.

 

Implementation, or deployment as some organisations call it, takes the detailed design, tools and information technology systems and implements them in the organisation. It is during this phase that the new processes and systems will “go-live” and be proven for real in the business. Typical activities in this phase would include deploying tools and information technology systems, data migration, training of staff and performing process qualification. We would recommend that there is a formal “go/no-go” decision made immediately prior to the first “go-live” of any new capability and that this decision is made by the steering team. This will ensure that the project and organisation are ready.

 

Having successfully achieved the “go-live”, the job of the project team is not over. The project team needs to support the initial implementation of the new capabilities until they are stable and handed over effectively to the people who will operate them and support them on an ongoing basis. This phase of the project would normally include the following activities:

 

  • Managing the cut-over from old capabilities to new capabilities.
  • Providing increased support to users during the initial period after “go-live”.
  • Ramping up new capabilities to design capacity.
  • Actively identifying issues in the new capabilities and rectifying them.
  • Completing process qualification.
  • Decommissioning redundant capabilities.
  • Closing out all project activities and reporting.

 

In the next article in this series, I will look at the key roles required to undertake such projects, and in later articles the programme management aspects of an artwork improvement programme.

 

If you have any thoughts or comments on this blog please contact me at  Andrew.Love@be4ward.com

No Comments

Post a Reply