I regularly hear the following questions and comments about projects that are either complete, or in flight:
‘Which methodology have you used?’
‘That should/shouldn’t be happening if you’re using that methodology’
‘You need to follow a methodology to the letter, otherwise it’s ineffective’
In my experience building a tailored approach, rather than rigidly following a methodology, will meet the objectives of the project. If the different phases and processes in your approach can be clearly defined and articulated, then you have created your own methodology – don’t be pigeon-holed by a name!
I was recently part of a SAP BPC 10 (Business Planning and Consolidation) implementation, adopting a tailored approach that loosely combined elements of Agile and Waterfall. In this blog I’ll aim to explain how we did this, as well as the benefits for the customer, the project and the team.
The scope of the project was to build an integrated financial planning solution using SAP BPC, providing a consolidated view of all revenue streams and costs. The headline business case for the project was replacing lots of cumbersome and time consuming spreadsheets that required consolidating after budget and planning cycle completion.
The implementation of the solution was time critical and needed to be business ready in time for the customer’s next budget cycle and we had clear, challenging timeframes to work within - 3 months from kick off to go live.
In light of this we produced a highly detailed Blueprint document to clearly demonstrate what we were going to build to ensure complete alignment with the customer and avoid losing time later in the project through design changes. In addition a small prototype was built in order to give the customer early visibility of the look and feel of the system they would be adopting.
We wanted to work in a way that would give the customer confidence of the solution meeting the go live date. BPC is a product that lends itself to an iterative build process – models within BPC can be divided across a project team and built in parallel. We steered the project towards this approach, planning in a series of functionality playback milestones. In all we completed five playbacks, with development continuing as each model was signed off.
Given the timeframes, we wanted to identify any issues and risks as soon as they arose, and monitor the progress against the project plan on a very regular basis to flag any slippage and mitigate appropriately. Weekly team meetings weren’t going to provide adequate control for this project, so we decided to run short daily meetings, with a scrum format:
What did you achieve yesterday?
What will you achieve today?
Are there any issues/blockers standing in your way?
The team valued having 15 minutes each morning to communicate any issues and concerns as well as tracking progress. Every day this resulted in sharing ideas and solving problems together.
Integration testing of each model of the solution was conducted once the design playback was signed off. This meant running five testing sessions throughout the build phase, with a final UAT phase when the solution was built in its entirety.
Testing throughout the life of the project meant the customer was comfortable with the functionality of the solution ready for their business critical go live. Key users of each model were invited to playbacks and testing sessions meaning change management within the customer organisation was made much easier, and the wider user base was bought in to the change.
I spoke to the users throughout the project about the approach, and it was interesting to hear things from their perspective. The key things that stood out were:
They liked the clarity of a blueprint document with clearly defined requirements, and the prototype helped them visualise what they would be working with
They liked regular playbacks – it provided a quick and easy forum for feedback, and also meant they were familiar with the solution straight away. In addition, regular visibility gave the project board confidence of working to challenging deadlines
Testing ‘on the fly’ provided the opportunity to raise defects and issues much earlier than a test phase at the end of build. Also, it made the key users’ lives much easier to introduce change in the organisation, having tested the solution throughout the project.
The end result was a project delivered against extremely challenging timeframes that the customer was happy with. The iterative build process, combined with a robust blueprint and visualisation in our blueprint, resulted in no change requests – and none have been raised since go live.
As with any approach to a project, there are steps to follow to ensure success:
It must be fit for purpose! All of the requirements for the project need to be understood before adopting an approach
All parties – customer, project team, project board – need to have a clear understanding of, and alignment with the approach.
A review needs to take place. Was the approach the right one for this engagement? How could it be further tailored and refined? How would you do things differently?
So, there’s an example of taking components from different methodologies to deliver a successful project. I still haven’t found a name for it yet though!