Navigating pitfalls in solution delivery
James Snyder is a Certified Master Anaplanner and Practice Director - Supply Chain at Allitix Inc.
As a consultant, my purpose is to build solutions for my clients that deliver value. I take great pride in my work and in driving meaningful change in organizations. However, the best laid plans can unravel as you move through a project. Throughout my project engagements I have come up with warning signs and considerations on how to manage the bumps in the road. Consider this a starting point to evaluate options to align and manage expectations. Ultimately you should always advocate on your client’s behalf and be vigilant in identifying risks.
Tips for navigating pitfalls in solution delivery
Scoping
In the sales cycle, you need to determine what the client is trying to accomplish. At this point you should be on the lookout for the following: Do they have a vision of what their business process should be? What resources are they willing to commit to the project? What is the state or their data? Overall, you need to assess readiness and determine what actions you should be taking to make your partners / clients “more” ready. During this period, you should be cataloging potential risks to be on the lookout for during the project. These will include data readiness, change management hurdles, and gaps in the business process.
As you assess, you may determine that a rapid agile foundations phase may not be appropriate; there may be a considerable amount of work defining to-be process. This may require some level of sharing industry standard practices (1). It also may be drilling into their vision and their perceived path to get there. For example, the client may be interested in deploying statical forecasting or using PlanIQ, but the client’s broader team might not be prepared for that transition. As a result, the roadmap may need to be aligned to change management hurdles to: 1) get the client on the Anaplan platform with the initial benefits of connected planning, 2) an evaluation period that acclimates the business to alternative forecasting methods, and 3) a cutover plan that leverages the learnings in the evaluation period.
Foundations
As the project is green-lighted and you move on to the foundations phase you should be on the lookout for some of the risks you cataloged during scoping. You may consider bringing forward requests for data ahead of formal user stories. Getting data ahead of user stories will let you know 1) the difficulty for the client to produce data, and 2) the quality of the data. However, the most important thing to look out for is client engagement. Management may be signed up for the project, but the rank and file may be skeptical. This is where soft skills play a significant part, because the success of the projects is that the rank-and-file take ownership of the solution being developed. This is where The Anaplan Way delivers its value.
The true value of The Anaplan Way is not that it is a foundation for rapid development, but it is a mechanism for continuous engagement with the client. However, the first cracks in The Anaplan Way can start in the foundations phase. The biggest hurdle for many clients is time. The client is likely deploying Anaplan to redirect effort away from non-value-added activities, e.g. maintaining excel models, but to do so they need to invest time in delivering a new solution. The first snag is therefore user stories. When the client is pushing back on writing user stories, it is an easy trap to fall into to write them on the client’s behalf to move the project forward. You should NEVER write user stories for clients, but you can help ease this burden.
Halfway through the foundations phase you should produce a process flow that acts as a blueprint for user stories. You can work with the client to organize these into epics and set some initial placeholders for user stories and assign owners for user stories/epics. This paired with workshops should be enough to put them on the right track. Once you cross the line of writing user stories for your client, their level of engagement and risk adopting the solution will be negatively impacted.
Build and test
During the build phase it is paramount to maintain engagement with the client teams. The key thing to be on the lookout for is how the client makes decisions. Are they collaborating in cross-functional groups to arrive at the optimal outcome or are they assigning a single owner to drive the solutioning process? My preference is the latter. By having a group decide it is difficult to assign ownership. If the group has difficulty reaching consensus, then who is responsible? It is much better to have one person be the owner of a user story or epic. This single owner is then responsible for developing an approach with the Solution Architect / model builder, validating the approach with a broader stakeholder group, testing the functionality when it is built, and then presenting the functionality to peers and management during retrospectives. This approach assigns ownership to the client and clarifies the deliverables of the client team.
Similar to the level of effort required in writing user stories, there is also a considerable time spent on writing user acceptance test scripts. The value of this task should not be underestimated. Back in the scoping and solution design phases in foundations consideration needs to be given to that the more that is built and the more complexity that is delivered, the more that will need to be tested. The more that needs to be tested, the more test scripts will need to be written. This is by no means a bad thing but should be a consideration for how much work the client team can absorb.
As you organize testing this should not necessarily follow a 1:1 ratio of test script to user story. At this point of development, the application has likely manifested itself differently than the user stories and business process flows in foundations. Typically, one should consider aligning test scripts around dashboards. Ideally the functionality owners assigned during the build phase should write the test scripts, but the work effort may not be evenly distributed. This presents an opportunity for members of the broader stakeholder group to be further engaged. A stakeholder might not have had the opportunity to fully own the development, but they have skin in the game to make sure that the functionality works for them.
Conclusion
Having worked on many projects over the course of my career, the one thing that makes or breaks them is people. Maintaining a level of engagement is key. There are early signs where engagement may flag, and it is your role as a trusted adviser to highlight risks when they arise. However, this is the client’s project, your role is to offer guidance, and ultimately the decision on how the project moves forward is theirs. Your client may go against your recommendation, that is their prerogative, but your role remains unchanged in supporting them on their journey.
…..
(1) Note, I didn’t say “Best Practices”. In truth the “Best Practice” is to do what is appropriate for your business and not what everyone else may be doing.
…..
About the author: James has 20+ years of professional experience with a proven track record in delivering financial and operational objectives. Extensive experience in analyzing operations, developing strategic roadmaps, and reporting on financial objectives and business initiatives.