This week we kicked off Project Santa. This is an ambitious internal project that will incorporate the use of various SAP technologies in order to drive business change. The timescales are pretty tight so we’ve decided to deliver this using agile methodology.
For some background to the project, check out the blog I wrote last week.
One week in and a lot of progress has already been made, the teams have been finalised and the roles confirmed. Following Monday’s kick off meeting it was full steam ahead with various requirements gathering sessions, the first playback workshop focusing on the overall flow and technical architecture and daily scrum meetings.
Now we have a pretty good idea as to what needs to be in scope and what is simply a ‘nice to have’. Oh and by the way, we have already had to contend with the normal project curve ball thrown in by one of the stakeholders (isn’t that what commercial directors are for?).
For those of you interested in the solution, the scope here is to implement an integrated project planning and tracking solution combined with some mobile functionality around timesheets. The high level scope is still as per the original proposal but three days in & we have a re-written plan, which has involved us totally changing the fazing of the sprints. The overall time scales haven’t changed but when we looked at the detail of what needed to be built it was clear that we needed to combine the first two sprints for the planning and BI part of the solution but run mobile concurrently to get the best outcome.
So what about the agile side of things?
What’s good about it from my perspective and where are the challenges to date?
The daily scrum meetings are great. They take place at the start of each day and for no more than 15 minutes. It means that I & the rest of the project team understand exactly what everyone is working on, what they achieved the previous day and more importantly, if there is anything blocking their progress. The team know they have time from the business on a regular basis, so they can ask questions without slowing down the timescales.
Knowing we’ll get visibility of parts of the solution as we go along is extremely useful and positive. For example, three days in we were shown a prototype of parts of the mobile solution. This really brought it to life. Okay so it wasn’t integrated, but rather than simply present diagrams and example screens in PowerPoint they built directly into the device giving a much more realistic and valuable experience.
Do I feel yet that I know exactly what will be delivered at the end of the project? Not really. We’re only 1 week in so it’s not an issue at this stage and might not even become one. But I suspect that the agile approach might mean that it doesn’t become clear until much closer to go-live. This is going to be make the communication to the end users & training & change management absolutely key.
However what I believe this means is we can absolutely make the best use of resources available and deliver as much functionality as possible within the time frames. Decisions can be made on what provides the best business outcome rather than what was necessarily laid out in a Blueprint document, months earlier.
Sprint 1 starts on Monday 29 November and we may further increase the challenge by upgrading to BW 7.3 as part of the ramp up program in conjunction with this project.
Watch this space...