Agile SAP in action: Project Dragon, the Project Manager's update - lessons learned

1 February 2012

Tom Jayne

Tom Jayne


In this Blog, I discuss my experiences managing Project Dragon - an internal project which aims to deliver an integrated Resource Management solution at Bluefin Solutions and also serve as a highly effective training exercise for our graduate intake. This is an ambitious task - it deals with a critical area of a consulting business, and involves new technology with an extremely tight schedule - 12 weeks.

11 weeks in, the scope of ambition has become even more apparent to me than it did in those opening days, but in terms of my own development, I probably wouldn't have had it any other way.

Where do we stand?

For those not keeping score, last week was pencilled in as the beginning of User Acceptance Testing - a phase I had wanted to dedicate two weeks to from the start of the project. In the grand scheme of things, two weeks is very short and I would not expect to attempt a two week testing phase again, but in relative terms this constitutes a sizable chunk of our project timeline.

Unfortunately, we could not meet our objective and begin UAT at the planned time. There are an abundance of reasons for this, but eventually reasons don't matter and you have to fix the problem instead of providing excuses. Steve Jobs used to give a speech to his employees at Apple when they were fortunate enough to be promoted to Vice President - explaining that the Janitor is allowed to have reasons to have not done their job, but as you move up the ranks those reasons are no longer an excuse. In Jobs' eyes, that boundary is Vice President Level, when justifications cease to be relevant.

I am not a VP at Apple. But I do think that Jobs is right, and it is a more fruitful exercise to think about where different approaches could/should have been taken, than to conjure up excuses and to not learn from the mistakes we all make. UAT kicked off with the first training session yesterday, so we are only one week behind where we wanted to be, but it is still important to determine why the schedule slipped. 

Here are some of the areas where, in hindsight, I would have done things slightly differently.

Using offshore teams

When splitting the project team into workstreams back in November, I thought a lot about how best to use the four graduates who have started out in Kuala Lumpur. In an attempt to make the team as integrated as possible, to try and take advantage of the time difference, and to give as much experience as possible, I split the graduates in KL up, assigning one to each of the four workstreams. See my blog Agile SAP in action: Project Dragon PM update - effective collaboration across remote offices. In hindsight, this was overly ambitious - as a team we have vastly improved at our communication but this has come at a cost - a lot of man hours on both sides. Given another chance, I would have assigned larger chunks of work to the whole team in KL, giving them real ownership and crucially, the ability to work as a team on a single goal.

Using a phased approach

As a software project, Project Dragon is slightly different in that the lion's share of the business value is derived from a relatively small part of the delivered solution. The bulk of our work has been focused on producing a Resource Management tool with SAP BPC, but the value, and impetus for the project, comes from SAP BusinessObjects reports enabled by having this integrated system. So far so good, but the development of these reports is heavily dependent on a completed SAP BPC solution, so attempting to produce these in parallel has been inefficient. I don't think a phased approach, producing one and then another, would have necessarily been faster, but it certainly would have been a better use of resources.

Communicating with the Client

This one is especially relevant to us, as a graduate group, and even more so now, when we are experiencing schedule slippage. Even within our own company, we have to build trust, and this can only be done by repeatedly demonstrating expertise and that we share the vision of the business in what is to be produced.

We all work in the same office, so it is very easy to pop across to the resourcing team and explain the current state of play or share any ideas. This can backfire as people have jobs to do, but done right it builds the relationship between the two parties and keeps the project transparent. This is especially important when things are not going to plan, as it allays people's fears that things are not under control. Almost invariably it has been external factors that have been the main blockers to progress - if these are explained in the right way then the client understands the situation and most importantly doesn't assume the worst. As a team we have not been fantastic at feeding back in a proper and regular fashion, and the sense of unknown that this creates is much worse than managing the expectations ahead of time.

Picking a methodology...and sticking to it

Because of the tight timescale, I chose to go with an Agile implementation, as a 12 week project cycle does not warrant a traditional waterfall approach. This is all well and good, but once the decision was made I struggled to keep everything in line with the Agile approach. The team worked to create an index of User Stories, but we have not referred back to them as much as we should have.  I divided the project schedule into sprints, but found myself slipping back into the more traditional Blueprinting/Realisation/Testing terminology. Occasionally I allowed us to forego the morning scrum in favour of other tasks - which completely negates half the value of a scrum - getting a bunch of people with different jobs to feel like a team again.

In short, the project is Agile in name, but not always in nature. This is for the most part fine, but when you start thinking about the project in other ways you lose one of the key benefits of sticking to a implementation methodology - knowing exactly where you are at in relation to the plan. A strategy provides a barometer to compare and monitor progress against, and as soon as it is ignored the ability to do that is jeopardised.

In summary

For a team of brand new consultants, most fresh out of University, I think the project has gone remarkably well. There have been the highs and lows which come with the territory, but overall to be so close to schedule when flying solo for the first time is something to be proud of. I cannot claim to be the reason for this - at the end of the day it comes down to hard graft and putting in the hours from each member of the project team, so I can only be thankful. From next week, even more members of the team are being siphoned off to client projects, so it is even more difficult to predict what the future holds for Dragon, but she is not finished yet, so stay tuned to see whether we get that all important UAT sign off in time.

View comments


Blog post currently doesn't have any comments.

Bluefin and SAP S/4HANA - welcome to the one horse race

We use cookies to provide you with the best browsing experience. By continuing to use this site you agree to our use of cookies.