Practical Guide to Managing Software Implementations

The major reason software implementations fail is not because of poor execution, or even because of unrealistic timelines or requirements.  It's because we don't have time.  Especially in small or medium businesses, team members are often wearing multiple hats, taking on a lot of responsibility, and when a significant project is put on their shoulders, things fall through the cracks.

This guide is meant to help those who feel like they are too busy.  It's not meant to be read in one sitting and remembered. It's structured so it can be skimmed, then come back later as needed. An experienced manager should be able to use the structure to remember what comes next and reduce some mental load. A less experienced project manager can use the detail to know how to perform each step.

There's not really a shortcut to a successful project. It takes effort to get everyone in a room and map processes and data, to make decisions that result in changes many teams will resist. But especially with software projects, being detailed and organized is a major part of any success.

If you're too busy to read the full guide, hit these key points and come back to the full sections when you have more time.  If you're the Project Sponsor, you might be able to stop at the key points.  But the Project Manager should review this document in detail so they are prepared for all of the required steps

• Understand the responsibilities of the Project Sponsor and Project Manager found in the Fundamentals section
• Review the Key Deliverables within each of the 3 stages

CONTENTS

Fundamentals

• Project Team
• Type of Implementation
• Project Management Triangle
• Managing Hidden Estimation Buffers

Stage 1 - Discovery

• Process Mapping
• Data Migrations and Integrations
• New System Review
• Key Deliverables for Stage 1

Stage 2 - Planning

• Decide On Type of Implementation
• Process Alignment
• Project Organization and Documentation
• Key Deliverables for Stage 2

Stage 3 - Execution

• Set the Tone Early
• Test, Test, Test
• Goal of No Surprises
• Key Deliverables for Stage 3

Common Issues and Potential solutions

Appendix - Project Documentation

FUNDAMENTALS

We'll start with a few key fundamentals.  The purpose of this section is to highlight a few key points that are important to understand outside of the actual project stages.

 If you plan to skip this section and come back to it as needed, make sure that the responsibilities of the Project Sponsor and Project Manager are clear before continuing.

Project Team

The point of the Project Team is to create "just enough" ownership.  Everyone on this team will be busy with other things.  And it's ok if they wear multiple hats during the process.  But their roles are important and need to be called out.  At a minimum, the Project Sponsor and Project Manager need to be decided on early in the project so they can lead the rest of the process.

Project Sponsor

Ultimately owns the project and the outcome.  They dictate or approve the budget and have the authority to resolve conflicts across teams.  This person shouldn't be part of the IT department.  They should represent the business: the highest ranking person possible within the scope of the new software.  Some project management terminology describes a Project Champion as a separate role.  But for the purposes of a small business, those responsibilities are often combined.

Key Responsibilities

• Champion the implementation of the software at all levels of the organization
• Own the outcome, control the budget, remove obstacles to keep the project moving
• Keep attention and energy on the initiatives

 Project Manager

Owns the execution, coordination, and daily momentum of the project.  They plan the meetings, keep the schedule, organize the notes.  If tasks are getting delayed, they provide the gentle reminders to keep on top of it.  They'll reach out to the Project Sponsor for help when their reminders aren't keeping things going.  They don't need to identify all of the tasks, but during the discovery phase they might need to sit in and be the note taker while the Subject Matter Experts review the processes and identify the tasks.

Key Responsibilities

• Manage the tasks and the timeline
• Keep the project moving by making everyone accountable for their tasks and the milestones that need to be met
• Keep the project documents up to date and organized
• Identify and communicate project progress and any potential issues that need a resolution

WARNING:  While it's beneficial to have a project manager that is experienced and knows the system, someone that can make decisions quickly, it can be even more critical to have someone who can dedicate the time.  A project manager has to make sure meetings are happening, make sure everyone's tasks are being completed, and has the ability to drop everything to find answers that keep the timeline from slipping.  If a more seasoned resource is also deeply embedded in the task list, they might get buried in their own tasks and miss the opportunities for follow up that can keep a project on schedule.

 Subject Matter Experts

Responsible to identify the processes and the major steps that can't be missed. They should create the process guides and sit in to review the processes the new system offers.  They know the requirements and help communicate that to create the task list that will get the project finished.

Key Responsibilities

• Identify the major processes and the key requirements of each one
• Help document the processes and review the new system against the requirements
• Sign off on the UAT to ensure the system is ready for the processes they own
• Make sure their areas get the training they need to be successful

 Technical Leads

Responsible for building and configuring the system.  They don't define how the business should operate.  Their role is to implement the strategies identified during the discovery and planning stages.  Technical leads could be either internal or external.  The software vendor probably has an implementation team (with their own technical lead) that will work with an internal IT department on the technical requirements of hosting, access, etc.  There is also someone, probably internal, that will manage the system after implementation that should be included as a technical lead, if not already included elsewhere.

Key Responsibilities

• Build and configure the system according to the requirements given
• Provide input on effort and needed timelines to complete the required steps

Type of Implementation

 There are a few ways in which a system can be implemented.  The actual decision on how to implement the system will be done during the planning stage.  But it's important to understand the different options as the project gets started.

 Full Cutover

This approach switches over to the new system all at once.  After all parts of the system have been identified, configured, and tested, on a given go-live date, the old system is turned off and the new system is turned on.  At that point all operations occur on the new system and the old system is retired.

Pros

• Operationally simpler after the go-live date with only one system to manage
• All team members within the company are using the same system
• Cross-functional flows don't get split or become partial
• Ultimately a lower effort as work is done in a single system with no duplicates or double entries
• No need for cross-system integrations to keep data in sync

Cons

• Higher risk as everything has to be ready on the day of the cutover
• All users across all functions must be trained and ready to operate
• All functions must be mapped, tested, and ready for production
• Errors that come up must be fixed urgently as they could put a pause on all operations across the whole company
• Rollbacks could be difficult, or impossible, if worst-case scenarios occur

 Parallel Systems

This approach runs both the old and the new system at the same time.  Data must be entered in both systems during that time to keep both systems valid and current.  At some point in time after validating the new system, the old system is turned off and the double entry of data is stopped.

Pros

• Lower immediate risk as the old system is still being maintained
• Allows for real-world validation of all the processes before final signoff
• Training for users can be more gradual and allowed to take time
• There is more time to fix issues that occur

Cons

• Higher on-going effort as users must work in two systems
• Requires that data is entered in two places, creating duplicate work
• Potential confusion about which system is the "source of truth"
• Longer transition period that could ultimately result in a difficulty fully cutting off the old system

 Functional Phases

This approach is a hybrid approach where functional divisions are created.  Each functional department is switched to the new system on a separate timeline, using a defined cutover date.  Once the functional department is live, only the new system is used.  But across the business, both old and new systems are operational at the same time while other departments wait for their turn to go-live.  This requires that both systems must have a way to stay in sync.

Pros

• Allows for smaller projects that focus on a single function at a time
• No duplicate work within each function, meaning there is no double entry of data
• Potential issues are reduced to one team while the rest of the team remains operational
• Early phases can identify issues that would have plagued the whole company, and find resolutions before additional departments are implemented

Cons

• Data must exist in both systems while only being entered in one, requiring some method of data sync
• Teams might need workarounds if cross-functional processes aren't fully implemented until a later phase
• Longer transition period while each function is implemented and validated before moving onto the next department

Project Management Triangle

KEY CONCEPT:  If one side changes, at least one other side must shift.

 A core principle in project management is that Scope, Cost, and Timeline are all connected.  Two of them can be optimized, but the third will have to change as a result. 

 Scope

Identifies the requirements that are being delivered.  It answers the question: "How much is being done?"

 Cost

Identifies the resources available.  This could be purely monetary as services are paid for, or the use of internal resources that have a less direct hourly value attached.  It answers the question: "How much can we spend?"

 Timeline

Identifies the time it will take to be completed, including major milestones and ultimately the go-live date.  It answers the question "How fast can this be done?"

 Project Implications

When planning a project, it can be helpful to discuss this up front and decide what should shift first.  If the timeline can't be changed because it's tied to a lease of the physical space, then budget and scope will need to be the key factors when project changes occur.  Identifying this ahead of time can save a lot of confusion and possibly frustration.

 Managing Hidden Estimation Buffers

KEY CONCEPT: Manage whether work starts on time, not just if it finishes on time.  Projects slip more from late starts than they do from late finishes. 

Bad estimates for task completion are another major reason for project delays.  But the underlying reality is that people actually do a decent job at estimating the needed effort.  Delays caused by "bad estimates" are actually a mismanagement of hidden buffers.

 When a technical resource is asked for estimated effort to complete a task, they will inherently add a buffer. Even though the task itself should only take a few hours, extra time is added to account for the backlog or unforeseen issues.  This is communicated with statements like "I should be able to get to it next week."

 But this is the hidden problem.  If a technical resource provided an estimate of 3 days, they also recognize that the task will really only take them a few hours. The start of the task is allowed to slip for two reasons: 1) extra time to complete the task means other tasks are a bigger priority and 2) finishing "early" will reset expectations on future requests. By the time the task is started, the buffer has already been eaten and there's no room for error. Now any unforeseen issues result in a delayed delivery.

 The most realistic solution is a mindset shift.  Gather all of the estimates and allow people to put their own safety buffers in place; they're going to do it anyway.  But instead of focusing on the "delivery date", focus on the "start dates" or the "start triggers".  Communicate that mindset shift early.  Instead of following up with "will you have this completed in time?", the follow up should be "were you able to start that on time?".  If, instead of a start date, the estimate is framed as "It will take me 3 days from the time x task is done", then start that communication as soon as the other task is started.  "Task x got started today.  It's supposed to take 3 days to complete.  Do you foresee anything that would prevent you from starting on time?"

SOFTWARE IMPLEMENTATION GUIDE

Stage 1 - Discovery

Process Mapping

You have to understand your current processes before you will know how they fit within a new system.  But a common mistake is to create a detailed step-by-step instruction of each process, and then force the new system to match that guide.  The system you're implementing has a standard approach to how processes are done.  Often, these approaches will be an industry best practice.  Otherwise, why are you choosing this system? 

Instead of forcing the new system to conform, seek to understand the key requirements of your business and wherever possible, conform to the standard.  As processes are reviewed, you're looking for the "Minimum Viable Process", which is the simplest version of the process that still delivers value.  Conforming to a standard flow can save everyone a lot of time.

THOUGHT EXAMPLES:

• Which steps are absolutely critical and which are just a way of doing things?
• Which steps, if missed, would break this process and create chaos?
• Why is this process an exception?  What is required that makes it special enough to become its own thing?
• What must not break as this process is done?

Identify Major Processes

If your company has SOPs, use those as a starting point.  You're not documenting any steps.  You're only creating a list of the major processes that must be followed. 

NOTE: These are MAJOR processes.  If a customer has a unique order process, put that to the side to be reviewed as an exception.  The major process is "Wholesale Orders", not "orders for customer X".

LEAD: Subject Matter Experts (identify the processes) | SUPPORT: Project Manager (schedule meetings, keep scope at "major processes", capture notes)

Identify Key Requirements

For each major process, identify 5-10 bullet points that are absolutely essential.  Consider the thought examples above.  This is not a step-by-step guide, but only the key requirements that can't be missed or everything would break.  These requirements are non-negotiable.  Included in these requirements should be current friction points that you'd like to be solved. 

LEAD: Subject Matter Experts (define the requirements) | SUPPORT: Project Manager (maintain momentum, keep conversations focused)

Identify Exception Processes

Now that the major processes are identified, make a list of current exceptions to the rule.  With each exception, make a list of 3-5 bullet points (yes, shorter than the major steps) that highlight WHY this exception is needed.  Identifying why it exists should be the same list of what this exception requires that is different than the major process.

LEAD: Subject Matter Experts (identify the exceptions) | SUPPORT: Project Manager (ensure exceptions are justified) | APPROVE: Project Sponsor (approve of any major customizations that would be required)

DON'Ts:

• Don't start with edge cases. INSTEAD:  Identify the major processes so there is a clean definition.  Edge cases can then be described as a variation from the norm, labeling what is different instead of defining every step.
• Don't create a detailed map of every process before seeing what the new system offers. INSTEAD: Identify the key requirements to make sure the new system meets those requirements.  You'll have a better experience if you can conform to the industry standards the system is already setup for.
• Don't assume your process is sacred. INSTEAD: Separate the necessary requirements from the "just a way this is done" steps.
• Don't create customizations for standard processes. INSTEAD:  Use the standard processes as much as possible.  The system will run faster and will make the customizations that are required a lot less complicated.

Data Migration and Integrations

After operational processes are identified, the next step is reviewing adjacent systems and how they interact.

Data Integrations are part of your long-term operations.  They are required if any other system will need to send or receive data to the new system.

Data Migrations only occur during the implementation project.  They are required when the new system needs historical data that your current systems have.  Or when data needs to be loaded for testing purposes.

Both data integrations and data migrations need to be considered when planning to implement a new system.

THOUGHT EXAMPLES:

• How much historical data does the new system need?  Can it operate on currently open data or does it need the full history?
• What are the key fields used that are critical for reporting and understanding our business?
• What reports do we currently use that are not part of the regular processes already defined?
• Before the new system goes live, how can we use real data to ensure our testing shows real-life value?

List Current Data Sources

Make a list of the current systems being used and what data they contain.  Make note if the system would be replaced by the new system or whether it would remain.  Identify current integrations between these sources of data.

LEAD: Subject Matter Experts / Technical Leads | SUPPORT: Project Manager (initiate the discussions)

Identify Needed Integrations

Review the current systems list and see how the new system fits.  Make a list of the systems that will need to integrate into the new system.  Make sure to note which of those integrations exist currently and which might be new.

LEAD: Technical Leads/ Technical Project Manager | SUPPORT: Project Manager (maintain momentum)

Identify Needed Migrations

How much historical data will the new system need?  You won't fully know this answer until doing the new system review.  But reviewing the needs of the systems being replace can provide a general idea.  If the new system is an execution system, like a Warehouse system that operates against current orders, it probably doesn't need a full history and could only need the current item list and current inventory.  But a financial system would need some kind of history that would need to be migrated over.  At this point it might be possible to identify the size of that data set.  If the historical data is large, it might be possible to summarize the data for the new system so it has the needed history without replicating every transaction.  If there is already a separate reporting system, consider loading the full history into the reporting system and limit how much of the history is loaded into the new system.

LEAD: Technical Leads/ Technical Project Manager | SUPPORT: Subject Matter Experts (help identify needed data)

Make a High-level Testing Plan

The new system will need to be tested and having real data will make sure things are as accurate as possible.  The final plan will need to be made after the system is selected, but think now about how this can help during testing.  Getting the data integrations done early can allow live data to be downloaded and processed in the new system.  Migrating historical data can allow reports to be tested.  Using these processes in testing can validate that they are ready. 

LEAD: Project Manager (owns all project documents) | SUPPORT: Technical Leads (provide technical input on capabilities)

DON’Ts

• Don't test on random data and plan on validating integrations closer to go-live. INSTEAD: Get integrations setup early and use real-world data to test and validate against
• Don't migrate your full history for testing. INSTEAD:  Identify a smaller subset of data that can provide the necessary validations.  A smaller set of data can be cleared and reloaded after a few corrections much easier than trying to reload the full history.
• Don't ad hoc the data migration. INSTEAD:  Automate the migrations, if possible, so they are repeatable and there is some comfort that they are ready for the go-live day.  If automation isn't possible, create a detailed list of the manual steps and repeat this process a few times to validate that it works
• Don't wait until the go-live day to do a full data migration INSTEAD:  Load as much data as possible before go-live.  Years worth of data can already be loaded and ready to go.  Configured data (like product attributes, customer lists) can also be setup and ready to go.  Then on the day of go-live, only the new data from that large historical load needs to be brought in.

New System Review

Now that you have a list of key requirements, start going through a review of processes in the new system.  This is where you get to compare and contrast your current process with what is being provided.  Make a note of how the new system handles your key requirements, and whether it doesn't.  If you can do this review before making decisions, it can help you find the system that is going to work best for you without starting with a list of customizations.

LEAD: Project Manager (lead meetings, compare against process notes) | SUPPORT: Subject Matter Experts (review processes, provide input)

THOUGHT EXAMPLES:

• Does the default process include all of our non-negotiable requirements?
• How many of our exception processes become part of the standard because of the way the new system does things?
• When necessary, how easy will it be to customize the processes we need?
• What problems do we currently have that will be resolved by the new system?
• What problems will the new system create by not meeting our minimum requirements?
• Will the amount of required customizations be worth the cost and effort to implement this system?

Review New System Processes

If possible, have a salesperson walk you through the major processes you identified and see how the new system does things.  If a personal review isn't possible, dig through the documentation to see how it's done.

Align Processes

Make notes of how many of the non-negotiable requirements are met by the default processes.  Also make a note of whether the default processes pull the exceptions back into a standard flow.

Identify Friction Points

Make notes for which current friction points (identified by the key requirements) would be solved by the default processes.  Also make notes about what new friction points (identified by the LACK of meeting key requirements) would be introduced.

Identify Customization Requirements

After the detailed review, make a list of the customizations that would be required.  Consider how important each customization would be.  Every system has some kind of workarounds.  We hate to normalize them, but they are also a reality.  Make note of what those might be early because it can either be a list of future requirements, or frame what the experience with this new system would be.

DON'Ts

• Don't settle for a high level review. INSTEAD:  Be assertive and review all of the key requirements to see which ones fit.  If you have a personal representative, ask about the exceptions, the workarounds, and how those are handled
• Don't assume your process is sacred. INSTEAD:  Review the new system with an open mind. Consider how the new system will help elevate your processes by standardizing them.
• Don't ignore potential issues by agreeing that you'll review it later on. INSTEAD: Make sure the questions are answered up front and there is a clear picture how the system will work for you.  You'd hate to waste people's time by finding out during implementation that something was skipped over and isn't possible.

Key Deliverables for Stage 1 Discovery

• Process Guides for each major process:  Not detailed, but containing the 5-10 essential bullet points that explain what is non-negotiable and must not break.
• Process Guides for all exceptions to the major processes.  Not detailed, but containing the 3-5 reasons why this process must be unique from the standard.
• Process Flows from the new system, detailing the standards of the new system
• Notes that detail the alignment of the new system processes to the necessary requirements
• Notes that detail the friction points that are resolved with the new system and new friction points that will exist with the new system.
• Notes about the needed Data Migrations and System Integrations

Stage 2 - Implementation Planning

Decide on the type of implementation

With a clear understanding of the requirements, and also an understanding of the new system's capabilities, the first decision to make is how the system will be implemented.

LEAD: Project Sponsor (overarching decision) | SUPPORT: Project Manager / Technical Leads / Software Vendor (provide input on capability)

THOUGHT EXAMPLES:

• Do we have the time to use both systems in parallel?  While it provides more time for training and fixing issues, is it practical to try and keep both systems accurate at the same time?
• Is this a large project that seems impossible to get everything lined up at the same time for a clean cutover?
• Would it make sense to develop data integrations between the old and new system while we implement the software one function at a time?
• Is the project small enough that it's easy to just get everything setup and cutover at once?

Process Alignment

This step was already started while reviewing the new system.  But a formal review and agreement on the alignment is needed before moving forward on the project.  This step identifies "What needs to be done".  It's during this step that the Statement of Work (described below) begins to take shape.

Decide Final Processes

Review all of the notes from the discovery phase and decide on the final processes.  Identify which ones will use the standard flows and which ones have exceptions that will need customization.

LEAD: Subject Matter Experts (finalize their processes) | SUPPORT: Project Manager / Software Vendor (provide support and direction)

Create Training and Documentation Plan

The final step-by-step guides won't be created at this step.  These will be created as you get trained on the new system.  But at this step, decide when and how that will happen. 

LEAD: Subject Matter Experts (create their process guides) | SUPPORT: Project Manager (provide assistance in documentation)

THOUGHT EXAMPLES:

• Does the software vendor already have a standard SOP to follow? 
• Can the person be trained create these at that time? 
• should a separate person be in the training, focused on creating these step-by-step guides?

Discuss Major Issues [OPTIONAL]

Have a "risk management" discussion around how to handle major failures at go-live.  Make a plan for potential solutions if the go-live brings down operations.  The process review already provided a list of what can't be broken.  Identify how those could be accomplished temporarily if the worst-case scenario is realized.

NOTE:  This does NOT need to be a detailed disaster recovery plan, or even be discussed at all.  But having this discussion, even at a high level, can bring alignment for even smaller issues that come up along the way.

Project Organization and Documentation

Official project documentation can take many forms.  It can be simple enough to exist only on handwritten notes or require software systems to manage the project complexity.  A simple Excel sheet can go a long way in creating structure and organization.

Some of these documents will be overkill for small projects.  But they can also scale to match the project needs.

See the appendix for key considerations and a minimum field list that can assist in creating these documents.

Document Summary

• Project Summary  - [OPTIONAL - HIGHLY RECOMMENDED]
• Statement of Work - [REQUIRED]
• User Acceptance Testing - [OPTIONAL]
• Testing Plan - [OPTIONAL]
• Identify Milestones - [REQUIRED]
• Budget - [REQUIRED]
• Communication Plan - [OPTIONAL]
• Issue Management - [OPTIONAL]
• Change Management - [OPTIONAL]

LEAD: Project Manager (owns all project documentation)

Project Summary [OPTIONAL - HIGHLY RECOMMENDED]

Unless the project is being managed by a professional Project Management Office, the Project Scope and Project Charter should be merged into a single page Project Summary.  This combined document defines key details that are important to have outlined before the project gets kicked off.

While optional, this could benefit even small projects by identifying what the project IS and what the project ISN'T as well as key players and their responsibilities 

Statement of Work  (Scope) [REQUIRED]

This is the project task list or project schedule.  As the process alignment is being completed, this is where the steps required to complete each process flow are recorded and maintained.  The list of tasks needs to be detailed enough to show the work that must be completed for the project to be successful.  It should exist on every project, but will grow in complexity as the details of the task list are increased for more complicated projects.

Break out the tasks into functional groupings with category, major process, department, or whatever might make sense.  The key to a great project is small, actionable steps.  Breaking a large project into smaller projects, highlighting key milestones, helps keep it achievable.

Identify and record task dependencies.  Not every task needs to list its dependencies.  For major dependencies, make an effort to identify start dates or "start triggers".  A start trigger might look like this: "Task B can be started when Task A is complete".

Estimate task efforts; how long will the task take to be completed.  Large projects with complicated timelines might require an estimate on every task to build out the timeline.  You don't need them all standardized, but be aware of efforts given in hours, days, or weeks. 

A more manageable approach might be identifying broader timelines for larger groups of tasks: "Installing and making the system available will take 1 week". 

Understand the hidden buffers built into the tasks.  When given delivery dates, work backwards and identify start dates for each task or group of tasks.

User Acceptance Testing [OPTIONAL]

UAT is a process where end users review the system and essentially sign off that things are ready to go.  As the UAT can serve as a form of process guide during testing, it might be impossible to create a full UAT guideline until the training on the new system has been done and detailed process guides are completed. Start with what is known, the key requirements that must exist within each process.  As the project progresses, add to the UAT so it's ready when testing starts.  A policy to ensure the entire UAT document is approved before the project can go-live can help make sure there are no surprises.

A UAT can be simple, defining the steps to walk through major processes and their exceptions.  But for a more detailed validation, merge the UAT with the testing plan (described below) to make sure the test not only validates the process flow, but that it's also ready to take on scenarios the business faces on a daily basis.

This could be overkill for smaller projects. 

Testing Plan [OPTIONAL]

At a minimum the UAT defines the processes that need to be configured so the system is ready.  But a testing strategy would identify additional scenarios to ensure that user testing covers what will happen in the real world.  It doesn't just indicate that a certain process will be tested.  It covers how the data for that test will be created, how will integrations to existing systems surrounding that process be tested, and what kind of scenarios within the standard process need to be reviewed.

This plan is important for identifying how data will be used to test the system and what tests are being completed.  But a full detailed testing plan might be overkill for smaller projects or projects without much data integration.

Identify Milestones (Timeline) [REQUIRED]

With the task list and testing plans in place, identify the major milestones of the project.  After extracting the milestones from the statement of work, do a quick reality check to make sure the milestones make sense based on the work that is required.

Once the milestones are identified, use those to identify a target go-live date.

Every project should list major milestones and an expected completion date.

Example Milestones

• When will the system be setup and ready for configuration?
• When will the data integrations be ready to start pulling down real data?
• When will the first set of major processes be configured and ready for initial review?

Budget (Cost) [REQUIRED]

With detailed scope and expected timelines, finalize the budget on the project.  Review the initial system cost and what is included in that.  Add any customization requests or any other details that came up during the planning phases.

A more complex budget document would list each line item of costs with a way of identifying that line.  With that established, the Statement of Work can be tied to how that particular task is being funded.  Is the task part of the initial project budget or did that get included as part of a customization request?  Put the ID, or descriptor, of the budget line as an attribute of the task records.  At some point in the project, this could provide a quick review of how to reduce the scope if the budget is getting out of control.

Every project should have some form of budget tracker even if it's simplified.

Last Review SOW, Milestones, Budget

With the scope, timeline, and cost established, do one final pass to make sure all of this still lines up.

Once finalized, update the Project Summary to include the established major milestones.  Statements about what is IN and what is OUT of scope can also be updated based on final plans.

Communication Plan [OPTIONAL]

Communicating progress of the project is a key responsibility of the Project Manager.  A communication plan would establish frequency of meetings and how stakeholders can know the status of the project.  People are generally understanding that issues will arise and most conflicts come from being surprised by them.  Establishing a communication plan so that everyone knows what to expect can be the difference between a solution-driven mindset and a fault-finding mindset.

Smaller projects won't need a formal communication plan, but could still benefit from an informal one.

Issue Management [OPTIONAL]

Issues will arise during a project.  Defining how they will be handled before the project starts can keep things calm even in urgent situations.  At minimum, have a plan for how to communicate the issue and how to assign responsibility for the resolution. Issues that result in changes to the project will need some kind of approval (see Change Management).  Smaller issues should be more easily and quickly handled.  Decide early on where that line might be.

While logging issues could be important on any project, if not managed properly it has the potential of turning into a list of complaints without real direction.  On smaller projects, having a method of communicating issues might be more important than an actual log of them.

Change Management [OPTIONAL]

It's not realistic to expect every decision made at the start of the project to hold unchanged until the end.  Using a Change Management log and a formal process for approving changes can help communicate updates and reduce surprises and missteps along the way.  But keep in mind that it's not required that every change is approved.  The change management process should act as a gatekeeper to make sure the project scope, timeline, and budget don't slip unnecessarily without proper approval.

While documenting the changes will need to happen on almost any project, a formal Change Management approval process can sometimes be seen as restrictive.  It has the potential of slowing momentum on the project while necessary changes wait for review and approval.  Consider how to streamline changes while still keeping them documented.

Key Deliverables for Stage 2 Planning

• Agreements on the final processes that are not a step-by-step guide, but identify which ones will need some customization and which ones will use the standard processes.
• Project Summary document with high level details about what is and what is not included in the project, who is involved and major responsibilities, major milestones and details on how the system will be implemented
• Statement of Work that details all of the tasks required to complete the project, pulling together the process alignment into actionable steps to reach each milestone
• User Acceptance Testing tasks and a Testing Plan document that details specific scenarios to be tested, providing an assurance that the system is ready for go-live
• Approved budget
• Go-live and post-live agreements on ownership and responsibility
• Plans for communication, change, and issue management so there are no surprises during project execution

Stage 3 - Execution

Set the Tone Early

It's important for the Project Manager to set expectations early.  Consistent meetings, visible task ownership, and follow-up based on start triggers (not just due dates) will establish accountability.  Following the agreed processes for issues and changes should be done early so that "we'll handle it later" doesn't cause issues later on.

The system is developed and configured in early phases of the project.  At this time task completion will most likely be heavily skewed towards the Technical Leads.  General system training will also occur early on as the Subject Matter Experts learn exactly how the new system works for what they need.  They likely won't see much real-world data yet, and exception processes usually get reviewed later. But process guides, SOPs, and development of the UAT can all get started at this early stage as the general training occurs.

Test, Test, Test

As more of the system gets developed, and even customized processes are completed, testing will begin.  This is when busy teams start to let things slip and don't look at the new system in enough detail to know if they are ready. The UAT is exactly for this purpose.  It protects busy Subject Matter Experts from "drive-by testing" and prevents the project from slipping into "we'll fix it later".  

Issues and requested changes will be more common in later phases of the project as Subject Matter Experts start to see their data populated in the system and make attempts to do their work following the new guides. 

Treat the go-live as a "condition" and not just a "milestone".  Hitting a deadline is important.  But making sure the software is ready before it goes live can make the difference in how the project is remembered.

DON'Ts

• Don't take a casual approach to testing INSTEAD: Test against real scenarios and require UAT signoff
• Don't consider something finished if someone couldn't get all the way through the process INSTEAD: Insist that the issues get fixed and start the testing again, even starting over at the beginning to make sure the process is complete
• Don't go-live if something isn't signed off and ready INSTEAD: If signoff isn't possible, adjust the scope or timeline intentionally.

Goal of No Surprises

Reasonable people know that issues come up. Problems occur when people are surprised.  Even great projects sometimes have their deadlines adjusted when the reality of the project comes out.  A project with no surprises doesn't mean it didn’t have issues.  But warning signs were watched for and communication was frequent to make sure things were handled in a timely manner. 

Meetings are helpful to keep people on track, but their real purpose is communication.  They're a chance to check on progress, talk about issues, and resolve concerns. At a minimum, every meeting should confirm what got finished, what's blocked, and what starts next.

As the project enters later phases, check-ins and meetings will mostly likely be more frequent.  This isn't because tasks are more important.  But as the go-live date approaches, there is less time to handle changes.  Frequent meetings help make sure there are no last-minute surprises.

Key Deliverables for Stage 3 Execution

• Completion of the Statement of Work deliverables (configuration, integrations, training, testing)
• Regular meetings and check-ins to maintain progress and keep the project on schedule
• Completed testing and UAT documents that show the project is ready for go-live
• Communication around issues that inevitably arise and how they are being handled
• A successfully implemented software system

Common Issues and Potential Solutions

These issues aren't technical failures.  The most common issues in projects are coordination failures.  Catching them early prevents avoidable delays and last-minute chaos

Scope & Decision Drift

Common Signals

• We can just squeeze this in
• Let's decide that later
• Configuration not following planned guidelines

Solution

• Revisit the Stage 2 decisions
• Label it clearly as either In Scope or Change of Scope
• If it's a change, capture it in the change log and confirm the tradeoff (time/cost/scope)

Schedule Illusion

Common Signals

• Tasks marked complete if only partially done
• Tasks or testing pushed out just a bit; is there still time before go-live?
• Data migration is assumed instead of rehearsed

Solution

• Tie progress to the outcomes, not just checkboxes Example:  instead of "integration complete", it should be "orders are flowing and available for testing"
• Split partial tasks that are mostly done, allow the additional work needed its own timeline
• Enforce the requirement that UAT must be signed off, enforcing actual progress

Buffer Mismanagement

Common Signals

• Tasks start late but end on time
• Everything is "almost done"
• The plan looks ok, but nothing is finished quite when expected

Solution

• Reinforce the rule to manage start triggers, not just due dates
• Shift the mentality from "will it be done" to "Were you able to start on time?"
• If the task didn't start when expected, assume the finish date is at risk

Ownership Gaps

Common Signals

• I thought they were handling that
• Tasks are delayed because decisions aren't being made
• No clear owner for tasks, issues, or change decisions

Solution

• Reassign ownership immediately (even if awkward)
• Set these details for anything that is stalled Owner (one person) Next action Decision deadline
• Escalate quickly when needed

Overconfidence Before Go-live

Common Signals

• It worked in testing
• Users will figure it out
• We'll clean it up after go-live

Solution

• Treat these as readiness warnings, not optimism
• Enforce a hard rule that if the UAT is not signed off, it's not ready for go-live
• If "cleanup later" is proposed Label it correctly as a scope change and run it through the change management process Identify the risk that's being accepted by not having it completed before go-live

Appendix - Project Documentation

The following sections provide insights into key thoughts, components, and fields that can be used to create the documentation necessary for a successful project.  They don't need to be perfect.  They need to be clear, current, and consistently maintained.  Make them only as detailed and complex as your project requires. 

Project Summary

Key fields and considerations for creating the project summary include

• Name the Project Sponsor and Project Manager (named)
• Description of the project
• What is IN scope
• What is OUT of scope (especially details that might be considered in scope if not explicitly stated)
• High-level data migration and integration needs
• Project team members and their areas of responsibility
• Project Triangle priority statement: "If something has to give, this order dictates what shifts first"
• Major milestones (added during the planning stage)
• Go-live plan (owner, issue reporting method, response expectations)
• Post-live support plan (when does support transition to long-term ownership)
• Any other major statements or details that would be important to identify at the start of the project

Statement of Work

The SOW is the detailed task list that is used to plan, track, and deliver the project.  It should include tasks for:

• System install and initial setup
• Configuration and required customizations
• Creation of the SOPs and internal process guides
• User Training
• Testing and validation (including completion of UAT)

Some of the major fields to track in this list include the following

• Task ID
• Task Description
• Grouping
• Responsible Person
• Expected Start Date
• Required Finish Date
• Task Status
• Notes
• Budget Line Item (explained in Budget section below)

User Acceptance Testing

Some of the major fields to track include the following

Filled in ahead of time

• Process name
• Step within the process
• Description of the step
• The Expected Result after completing the step

Filled in as testing occurs

• Name of person who was testing
• The Actual Result after following the steps
• Tested? (Yes/No)
• Status (Open, In progress, Completed - Passed, Completed - Failed)
• Comments or Notes
• Issue ID (List of Task IDs to ensure the resolution is properly integrated into the SOW)

Testing Plan

When developing a testing plan, a list of key considerations would include the following

• When testing begins, what data will be tested against?  Will this be randomly created data or actual, current, business data?
• How will that data be loaded into the system?  Does that need to be done manually or can the Data Integration be setup and tested as part of this testing?
• Pulling data from a source system is usually lower risk than pushing updates back into it.  How will data pushed back to the source system be tested before go-live?  Will test orders be placed in the source system and processed?  Will a few live orders be processed in the new system so the integration flows pushing data back up are validated?
• What scenarios need to be tested?  This is more than just general process flows, but variations in data of the established standard processes.  While the UAT might have a validation for "Orders successfully created from the Shopify integration", a testing plan would include multiple scenarios: Orders paid for by credit card vs orders paid for by gift card Orders with only 1 line vs orders with a few dozen lines; will the new integration handle the largest order? Orders shipped with FedEx vs orders shipped with USPS Orders that require kitting or assembly of items Orders for specific key clients

Budget Tracker

For most projects a budget tracker will be simple and might only cost 1 line: the cost of the software.  But having a sheet that can track the cost of customizations, integration services, and other project costs helps keep scope and spending aligned. It also allows tasks to be linked back to a budget line, making tradeoffs between cost, timeline, and scope easier to manage

A budget tracker might record these details

• Budget Code (ID that can be used in the SOW so tasks can connect to a budget line)
• Description
• Category (Software, Implementation, Customization, Integration, Data Migration, Training, Other)
• Vendor (who is charging for it)
• Cost Type (One-time, Recurring)
• Estimated Cost
• Approved Cost
• Approved By
• Actual Cost
• Status (Proposed, Quoted, In Review, Approved, Rejected)

Communication Plan

A communication plan should identify these key components

• How often will the project team meet?  Does this frequency change as the go-live date approaches?
• How will task owners communicate their status?  Do they edit the task list directly, send emails into the Project Manager, or just report a status at the regular meetings?
• How will progress be communicated?  Is a system being used that has an automated dashboard or will a project summary need to be created?  Are users expected to log in to see the progress or will this be blasted to stakeholders by email?

Issue Management

An Issue Management plan should identify these key components

• How are issues reported?
• What is the process to see an issue through to resolution? Does it get added as a task or does the Issue Log serve as a separate, often more urgent, task list?
• How is it determined if an issue needs to be resolved, noted and watched for, or ignored?

An issue management log might record these details

• A description of the issue
• Who found the issue
• Date it was found
• Description of the possible resolution
• Impact to Time, Cost, or Scope
• Decision Needed? (Y/N)
• Escalation Required? (Y/N)
• Who was assigned to correct the issue
• An expected date to have the issue resolved

Change Management

A change management plan should identify these key components

• How are changes requested?
• How are changes reviewed?
• Who has the authority to approve or deny project changes?
• What happens if the change is approved or rejected?

A change management log might record these details

• A description of the change
• Who requested the change
• Date of the request
• Changes to Time, Cost, or Scope as a result
• Status of the approval
• Date Approved (if applicable)
• Approved By (if applicable)
• Date and Reason for being Rejected (if applicable)
• Issue IDs (List of Task IDs to ensure the change is properly integrated into the SOW)