The concept of “Plan Slow, Act Fast” in *How Big Things Get Done* emphasises the importance of meticulous planning before jumping into execution. It challenges the common tendency to rush into action, often leading to cost overruns, delays, and failures in large projects.
So for example,
Plan Slow
Take the time to get the planning right. This involves rigorous research, detailed scenario analysis, and clear alignment of goals. The idea is that spending more time upfront identifying risks, setting realistic timelines, and making data-driven decisions reduces the chance of surprises later. This phase also involves engaging stakeholders, refining the strategy, and stress-testing assumptions.
Act Fast
Once the plan is solid, execution should be swift and decisive. With all key decisions made and potential pitfalls anticipated, the team can confidently move forward without the need for constant re-evaluation. This approach minimises delays, keeps momentum high, and ensures resources are used efficiently.
In essence, investing time in thoughtful, strategic planning allows for faster and smoother execution, leading to better project outcomes.
So your organisation wants to buy and implement ERP software. If it’s a big scale rollout, how might you apply the concept of plan slow, act fast?
When buying ERP software, “Plan Slow” involves a careful, deliberate process before making any decisions. Here’s how you can approach it:
Needs Assessment and Goal Definition
Clearly define your organization’s requirements, objectives, and pain points. Engage with all relevant departments to understand their specific needs. This ensures that the ERP solution aligns with your business strategy and growth plans.
Stakeholder Alignment
Involve key stakeholders early. This includes department heads, IT, finance, and end-users who will interact with the system. Achieving consensus upfront prevents misalignment later and ensures that everyone’s priorities are addressed.
Process Mapping and Optimisation
Before selecting software, document your existing business processes in detail. Identify inefficiencies and areas for improvement. This is an opportunity to refine workflows so that the new ERP can be configured optimally, rather than just automating inefficient practices.
Vendor Research and Shortlisting
Research thoroughly potential ERP vendors. Compare their solutions in terms of functionality, scalability, integration, and support. Engage with current users of the systems you’re considering and learn from their experiences. Don’t rush this step—understanding the strengths and weaknesses of each solution is critical.
RFP and Detailed Evaluation
Develop a comprehensive Request for Proposal (RFP) and evaluate vendors based on specific criteria, like alignment with your needs, cost, flexibility, and future scalability. Invite vendors to demonstrate their solutions using real data or scenarios relevant to your business.
Scenario-Based Testing and Proof of Concept
Before committing, conduct scenario-based testing or a pilot program. See how the ERP handles real-world situations that your company faces. This is where you can identify potential gaps, integration challenges, and customisation needs.
Long-Term Planning and Risk Assessment
Consider the long-term implications, such as how well the ERP will scale, its total cost of ownership (including hidden costs), and the ease of future upgrades. Analyse potential risks, including vendor stability, data migration challenges, and potential disruption to operations during implementation.
Change Management and Training Strategy
Develop a change management plan and a strategy for training employees. Yes, use the plan slow idea with your business transformation to increase adoption and reduce resistance.
By slowing down and focusing on these steps, you’ll make a more informed decision that sets the stage for faster, more effective implementation later.
This is all very well, but how do you run a proof of concept and develop strategies when you don’t own the software?
Running a proof of concept (PoC) when you don’t own the software is a common concern. Here’s how you can still effectively evaluate an ERP solution without a full purchase:
Vendor-Supported PoC or Sandbox Environment
Most reputable ERP vendors offer a sandbox environment or a limited-time trial specifically for PoCs. This is a test environment where you can configure the software to mirror your business processes. Vendors often assist in setting this up, allowing you to assess core functionalities and integrations before committing.
Request a Custom Demo with Realistic Scenarios
Work closely with the vendor to develop a custom demo tailored to your business processes. Provide sample data, typical use cases, and specific scenarios relevant to your operations. The vendor can demonstrate how their ERP handles these situations in real-time. While this isn’t a PoC, it helps you better understand the software and how it might work within your organisation.
Pilot Programs or Short-Term Agreements
Negotiate a short-term, low-commitment pilot program (a sort of “try before you buy” idea). While it’s not common for all vendors, some will offer a limited deployment for a specific department or process. This allows you to test the system in a real-world setting with minimal risk.
Use Partner-Hosted Proof of Concept
Many ERP vendors have implementation partners who can host PoCs. These partners often have pre-configured environments that closely match your industry’s needs. You can collaborate with these partners to test critical features, customisations, and integrations specific to your business.
Plan A Scenario Based Conference Room Pilot (CRP)
A CRP is a structured, collaborative workshop where your team and the vendor work through predefined business scenarios using the software. This exercise helps you see how the ERP handles end-to-end processes, decision points, and exceptions, giving a practical insight into its suitability.
Case Studies and References with Similar PoCs
If running your own PoC isn’t feasible, explore case studies and speak to reference customers who have run PoCs with the same ERP system. Ask specific questions about the setup, challenges, and how closely their scenarios matched yours.
While these approaches don’t give you full ownership during testing, they provide enough insight to make a well-informed decision without rushing into a purchase.
So should you devote a percentage of your budget to this part of upfront slow planning?
Yes! A percentage of the full ERP implementation budget can be spent on an ERP proof of concept (PoC). Here’s how that could break down:
Factors Influencing the Budget Allocation:
Project Complexity and Scope
For large or highly complex implementations, a more extensive PoC might be needed to validate integrations, customisations, and specific functionalities. In such cases, a higher end POC budget might be justified.
Industry-Specific Needs
If your industry has unique or niche requirements (e.g., specialised manufacturing processes or regulatory demands), more investment in the PoC is warranted to ensure the ERP can handle these specifics.
Customisations and Integrations
The more tailored your ERP needs to be, the more critical it is to test how customisations and integrations will work. This drives up PoC costs but also increases the value of investing more upfront to avoid issues later.
Risk Tolerance
Organisations with lower tolerance for risk, or those with a history of failed ERP projects, often benefit from a more comprehensive PoC, which may push the percentage closer to the higher end of the range.
What the PoC Should Cover
A well-planned PoC should validate key assumptions and test critical workflows, including:
– Key business scenarios and value added software configurations.
– Integration with existing systems.
– User experience and interface usability.
– Data migration and quality checks.
– Customisations and automation capabilities.
ROI on PoC Investment
Spending a percentage of the budget upfront on a PoC can prevent significant overruns later in the project, saving both time and money by identifying issues early. This cautious investment aligns with the “plan slow, act fast” philosophy by ensuring that your organisation has a solid understanding of the ERP’s fit before full-scale deployment.
In summary, while the exact percentage depends on the specific needs and risks of your project, having a percentage of the total budget is generally the idea to achieve a thorough yet cost-effective PoC.
Even if you do a POC upfront, what are the project risks?
Running an ERP proof of concept (PoC) is a valuable step in the “plan slow” approach, but it’s not without risks. Here are the key risks to be aware of:
Scope Creep
The PoC may expand beyond its original purpose, leading to additional time, resources, and costs. If too many features or scenarios are tested, the PoC can become unfocused and overwhelming, diluting its effectiveness and stretching the budget.
Misalignment with Full Implementation
There’s a risk that the PoC does not fully represent the realities of a full-scale ERP deployment. If the PoC is overly simplified or limited in scope, it might fail to reveal critical issues that could arise during the actual implementation, leading to false confidence.
Incomplete Stakeholder Involvement
If key users and stakeholders aren’t fully engaged in the PoC, critical business needs or potential issues might be overlooked. Without the right people involved, the results of the PoC might not accurately reflect the organisation’s true requirements.
Underestimating Data Complexity
The PoC might not account for the complexity of data migration, integration, and cleansing. If real data isn’t used or the sample data doesn’t reflect actual conditions, the results can be misleading, causing significant challenges later when data-related issues emerge.
Overlooking Integration and Customisation Needs
A PoC that doesn’t sufficiently test integrations with existing systems or specific customisations can give an inaccurate picture of the ERP’s suitability. Integration issues are a common failure point during full implementation, so neglecting this in the PoC is a major risk.
Time and Cost Overruns
Even though the purpose of a PoC is to avoid problems later, it’s possible to spend more time and money on it than initially planned. If the PoC drags on or requires additional rounds of testing, it can delay decision-making and drain resources, ultimately reducing the value of the “plan slow” approach.
Vendor Dependence and Bias
When a PoC is heavily influenced by the vendor, there’s a risk of biased results. Vendors might configure the software to perform exceptionally well in the PoC while downplaying limitations. Work out how expectations can be more realistic (slow planned) for all parties.
Inaccurate Cost Projections
The PoC might not accurately reflect the full cost of the ERP implementation, especially if hidden costs related to licensing, customisations, or long-term support are overlooked. Over the lifetime of the solution, avoid underestimating the true costs.
Resistance to Change
Running a PoC without fully considering the organisation’s culture and readiness for change can backfire. If key users are skeptical or resistant, they may dismiss the PoC results, leading to pushback during full implementation. Effective change management must start early, even during the PoC phase.
Overconfidence from Positive PoC Results
A successful PoC might lead to overconfidence, causing the organisation to accelerate the implementation without adequately preparing for scale, complexity, or unforeseen challenges. This contradicts the careful “plan slow” approach and can cause issues later.
Mitigating These Risks
To mitigate these risks, it’s important to clearly define the scope and objectives of the PoC, involve the right stakeholders, and ensure the scenarios tested are realistic and aligned with the full implementation. Additionally, maintaining transparency with vendors and setting clear timelines and budgets are crucial to getting the most value from the PoC while minimising risk.