top of page

Prepare Phase

Phase Overview

Phase Overview

This is the phase where things really start to get going. Strategic decisions will have already been made with project goals and objects set. Initial funding and timeline targets will be set to support the business case but now need to be validated. In this phase you will need to mobilise resource capability to to get your project off the ground. Key roles will be appointed and initial partner support contracts in palace. Planning will be a primary focus which will need to be underpinned by a sound conceptual architecture and a first pass of a work breakdown structure so that packages of work can be planned and resourced. 

​

Formal project governance now needs to be established with necessary controls in place for scope management, planning, financials and resource management. Status Reporting should begin and governance forums established. 

​

At the end of this phase the project will be un and running, a plan will be in place and there will be clarity over what happens next. 

Deliverables

Key deliverables for this phase are listed below.  You should consider carefully the RACI associated with each of these which will in part be determined by your capability sourcing approach. 

​

Project Initiation Document  - all good projects have one! In the early stages of this phase this document will very much be a work in progress. In essence this document will capture how you intend to run this project.  It should owned by the main project leader and updated continuously throughout the project. This will be a useful artefact for resources on the project and also any assurance or audit groups that will later assess the project. 

​

Project Governance Framework - this will set out what your definition of project governance is and how it will operate. There is typically a hierarchy of governance starting with a Steering Group which is then underpinned by A Design Authority, A Project Management Meeting and a Change and Readiness  Forum.  You will also need to decide where to manage change control, financial management and commercial/ partner performance management.  Each group should have a terms of reference defined and then set out into a project reporting cadence which shows what reports/information flows from/to where and how often. 

​

Team Structure - Again this will be an evolving document as you progress throughout the project. It will be an important tool to provide clarity on who's who, how teams are organised and controlled. As a minimum each of the key roles should have a roles and responsible definition so there is clarity on who does what. As you get lower down the organisational chart some roles will become generic and filled by several people, eg functional testers. 

​

Resource Sourcing Strategy - you will need to determine how you will staff your project team and meet the capability requirements that you have to deliver the project. Insourcing verses outsourcing is often the big debate here. The key consideration at this stage is thinking about what capabilities will be one off and which will you likely need in an enduring team structure once the project has concluded.  Experience is also a key consideration - you must have experience within the team and you are likely to need to lean on a partner to help you get access to resource pools with experience. Where you decide to insource roles you will need to balance having experience of your organisation and also ensuring you have people on the team that understand the technology you are deploying. You will need to be able to hold your partners to account as well as benign able to collaborate effectively.   

​

Finance forecast  - it is really important to have a solid finance forecasting model agreed up front so that you don't lose control from the beginning. Any forecasting model needs to be able to support and align to your organisations regular financial accounting processes and also support the needs of the Sponsor and Steering Group who will have overall accountability for the project finances. Early forecasts will contain uncertainty and so it is important that a clear list of risks and opportunities are maintained and regularly reviewed through the project. You will need to ensure the project leadership team are clear on their responsibilities with regards to forecasting, that the PMO function are clear on processes such as forecasting, accruing, accounts payable, controls, approvals and accounting treatment (eg Capex vs Opex). On large projects (or programmes) it is usually a good idea to have a dedicated accountant 

​

Project planby now you will have a project plan in place, utilising a professional planning tool. The core structure of the plan should be formed, an initial critical path set driven by key dependencies. Resource loading should be in place as a minimum for the next phase. 

​

PMO standards  - an effective PMO is crucial to help keep your project under control. Defining your PMO operational processes early will ensure things operate smoothly from the start. Key things to include are resource onboarding, partner onboarding, reporting templates and timetables, ordering and approving purchase orders and invoices. Effective Document Management is also vital ensuring good audit trails, version control and a well structured library for both the project team and the enduring team. 

​

Scope Definition  - a clear articulation of scope written in business language. Key processes, applications to be replaced, interface flows, datasets are examples of things to be included.  A definition of project phases should be included too, such as test cycles, data migration testing. training etc.   Technical scope will be determined later which would cover things like infrastructure, integration and security

​​

Project Delivery Methodology 

​

Tech and SA deliverables at this stage. 

Licensing 

Assurance/Quality plan 

​​

​

Deliverables
Capabilities

Capabilities

In this section key capabilities will be listed to help you achieve producing the deliverables for this phase. The level of resourcing needed to provide these capabilities will vary depending on the size and scale of your project. On smaller projects a single resource may be able to provide several capabilities, whereas on larger ones you may need several people to deliver a single capability. 

​​

Project Management - the project (or programme) manager needs to have experience of the relevant ERP implementation. These are complex projects and previous experience is key, particularly if it is a large scale project. You may require several project managers reporting into a single senior project manager. You need to consider if your workstream leads have project management capabilities or whether they need to be supplemented with additional project management capacity - a great Technical Architect might not be such a great project manager for example, but they will still need to define and operate against a plan, manage RAID, produce reports, manage workload etc.  

​

Project Management Office (PMO) - The PMO team will keep the drumbeat of processes and governance going. These resources don't necessarily need to have ERP experience so long as they have a strong background in all things PMO.  Staff this part of your programme well and it will allow the project leadership team to focus on delivery challenges rather than project operational ones.  

​

Accounting - For large projects a dedicated accountant or financial analyst is recommended. Keeping on top of your finances is fundamental to keeping your project under control. Ensuring consistency with the wider organisational accounting practices and polies is also much easier with a trained finance resource at the helm. 

​​

Commercial - Contracts for products and service will be being put in place at this stage. A commercial expert will ensure you have the right terms and conditions, the right incentives and penalties defined, ensure consistency across different contracts and ensure you are as protected as you can be should you find yourself in a difficult dispute further down the line. 

​​

Solution Architecture - Conceptual Solution Architecture deliverables will be taking shape now. You need to ensure you have a strong architect who will not only ensure that the primary business requirements are met but also that you maximise your return on investment by getting the most out of the products you are buying. 

​

Technical Architecture - Understanding how the new solution will integrate into your existing IT estate is a key role. Defining and implementing non functional requirements will also fall to this role. 

​

Planning - on large ERP programmes this is a full time role filled by a planning specialist. Someone that understands how to sue professional planning tools and and build and maintain a complex multi workstream plan. 

​

​

​

​

Project Management Processes

Project Management Processes

Now the project is up and running there are a number of project management processes that you should be operating. These processes should be included in your phase RACI. 

​

Plan ReviewsNow that your plan is up and running it is important you agree with your responsible plan owners (those on the hook for providing updates) how that plan is to be maintained. Usually it makes sense the the plan to be maintained by 1 person so that that can help ensure the integrity of the plan as opposed to several different workstream leads trying to update it simultaneously. A good way to archive this is short weekly planning surgeries where the planning lead runs through tasks to get updates on dates and dependencies. Any material changes or impact to critical path will need to be reported to the project manager with either risks, issues or change controls raised as appropriate. After all the planning surgeries have happened a summary output should be produced and fed into the weekly status meeting for wider project leadership review.

​​

Status Reporting  - A weekly status meeting is usually standard practice and is a good opportunity for the project leadership team together, review progress collectively, discuss issues and impacts, review risks and review the plan across the full breadth of the project.  The status meeting needs to be drive by objective measures, typically coming from the plan. Adherence to milestone dates, material forecast variances and any dependency impacts should be included.  The RAID log should also be used for workstream level review although you may chose to limit the review to escalated items given the RAID log will likely have too many items to revie win a timely fashion with the entire team. It is also sometimes useful to ask the workstream leads to provide some commentary that gives a summary of where their workstream is at - a word of caution though, you should avoid this becoming the only for of update as it will often be subjective and you will find the plan and RAID logs can drift in to a state of being out of date. Driving status from these deliverables will help ensure they are maintained correctly. 

​​

RAID Management - Every projects needs an effective Risk, Assumption, Issues and Dependency process.  Often trackers are put in place but processes to maintain/run them are neglected.  The process needs to ensure regular reviews by the item owner, the escalation process is clear and utilised and basic housekeeping is in good order to ensure things like trigger dates, mitigation updates etc are maintained.  Assumption validation can sometimes be overlooked - just because it is written down doesn't mean its understood by all. Assumptions should be positively confirmed with the appropriate person with an agreed review date set.  Dependencies, particularly internal ones, will often be tracked via the plan and as such the planner can help ensure the dependency log is kept up to date. External dependencies will need to be proactively managed again with positive confirmation as to whether things have changed or not. Some of these will be outside of the projects control but could have a major impact on the project and so should be tracked at the Steering Group.

​

Commercial Control - At this stage of the project you will likely be onboarding partners to support you. Your Resource Strategy deliverable will have already considered what roles and capabilities to outsource. Once contracts are established (which may also include call off work orders) commercial controls will need to be put in place. A good forecast of payment milestones and how effort will be expended on a monthly basis if you need to account for value of work done. Invoice validation and approval steps need to be defined and aligned to any corporate policies on delegations of authority. Change of scope and escalation processes should be included within the contract and should align to PMO processes.  A regular performance review of your contracted partner should also be scheduled to not only ensure they are delivering on their commitments but also adhering to any agreed ways of working. Deciding whether to fix the price of the contract or agree it on time and materials terms is tricky. Whilst you think fixed price can offer you commercial certainty, at this stage of the project there are lot of unknowns and therefore twists and turns that are likely to render the fixed price agreement not fit for purpose. It may be better to wait until you have more solution and planning certainty. 

​

Change Control - It is a very important discipline and needs to be an efficient process to ensure it remains useful, otherwise it will be circumvented. Scope Definition, Contracts, Plans amongst other things need to be subject to formal change control. Changes need to be properly impact assessed by your workstreams so that effective decisions can be made. it might be possible for you to set change thresholds to enable decision making at a lower level where appropriate so that you don't overwhelm the change control process. 

​

Business Case Review - the business case needs to be regularly reviewed. At this stage it will be formed and will likely have had executive approval from within your organisation however, it is important to recognise it could still materially change at this stage until more information in understood about the solution and therefore the time and effort associated with deploying it.  Each of the key benefits needs a named Executive Owner to ensure that there is no ambiguity when it comes to defining, measuring and tracking benefits delivery. A monthly session with benefits owners should be facilitated to ensure the proposed solution will still enable benefits realisation and that nothing has changed in the business. 

​

​

Planning and Estimating

Planning and Estimating

What factors influence planning

​

What factors influence estimating 

​

When will these items become more certain

​

​

Risks/Lessons

Project to implement new ERP systems are often complex. Success rate statistics usually make for pretty bleak reading however there is a wealth of experience and information out there to help you avoid some common mistakes. Below are a few that are relevant to this stage of the project. 

​

1. Forecasts built on strategic bias - ERP projects are often high cost endeavours that can take a long time. This often puts pressure on making the business case positive in terms of tangible payback. For this reason strategic bias can creep in, trimming budgets, squeezing plans to make the numbers work. It truly is a false economy.  Your plans have to be based on experience, comparable projects and as much measurable information as possible. Cutting corners will only result in your project adding to the failed project statistics. 

​

2. The team needs to be built on experience - as referenced several times already on this page, you must ensure the team has good experience within it. It is of course ok to recruit people that will learn and develop on the job but they should be in suitable positions within the organisational structure. Blending business experience with ERP product knowledge is also keep so don't neglect training and on going coaching. 

​

3. Data Migration and Testing Cycles need to come together - you can't have a lesson learned section without mentioning data. On ERP projects you often see data and testing plans collide and compromises made. This usually because you cannot finalise the migration design until the configuration design is complete, but not long after it is complete the solution is ready for testing. Test data helps you get over this but projects fall in to the trap on then relying on that for the duration and only see the solution operating with an integrated data set at the point of go live. And that's not good. Your planning phase needs to allow for these two workstream to come together so that functional testing is done on test migrated datasets. 

​

4. Don't enter in to fixed price contracts too early - as with most projects there is a lot of uncertainty at the start. This will improve over time and so you must try to identify the optimal point at which you can enter into fixed price contracts with clear scope, dependencies, approaches and a calculated view of risk 

​

5. Understand what you are changing - Many ERP projects are also driving a level of transformation which could include implementing new Target Operating Models along with new technology and processes. If you don't know how you do it today it makes it very difficult to identify change and prepare for adoption. You can also find nasty surprises too late in the day in testing. 

Risks/Lessons
Governance

Governance

Effective governance needs to be established at this phase of the project. Below are some high level terms of reference for key governance forums. 

​

Steering Group - Your Steering Group is usually top of the governance hierarchy and often reports into the Organisation Executive Board or the CEO. The Steering Group is ultimately accountable for the success of the project from owning the Business Case, to ensuring the Project Leadership team are delivering on their commitments. Key dimensions are below:

​

Chair: Project Sponsors, typically those accountable for processes impacted by the project. It is important these are business stakeholders however give the significant technology component the CIO or CTO is also usually a co-sponsor. 

​

Key attendees: 

​

Purpose of a steerco. What is likely to be on their agenda at this stage 

​​

Status meeting - remit of control 

​​

Change control 

​​

Design authority -who should be on it. What decisions are they making

​

​

Next steps considerations

Preparing 

Next Steps Considerations
bottom of page