Once upon a time before the rise of the millennium, when the word Scrum wasn’t invented and the Agile Manifesto wasn’t written yet… Maybe then my today’s practice retrospective isn’t completely correct in saying “it recently happened”, but I had similar project situations over and over again in the recent years where the case told here is exemplary for.
Near to the standard but completely individual – is that feasible?
The case is about a pilot project for an ERP template which should be rolled out to all subsidiaries of a worldwide operating company subsequently in follow-up projects. To minimize the cost the template should keep near to the standard application, but yet it should also adapt market specifics, tax and legal requirements at the subsidiaries as best as possible. Squaring the circle?
So it turned out to be as to be expected: The Statement of Work (SOW) frequently was adapted to change requests for new or changed requirements from the branches, the headquarter departments took this as an invitation to generously insert their special wish list, too, and the forecasted cost blew all budget limits. Thus the project did what pilots always do when they do not receive a landing permission: it looped.
Agile and “classic” project management form a symbiosis
To get the project out of its requirements analysis and planning phase towards realization we decided to proceed iteratively starting with the core functionalities of the standard product. We agreed on a strategy to have complete and tested template ready to use within a certain span of time. This should be complemented and enhanced by prioritized increments subsequently until either the time and budget frame was spent or the template had sufficiently met the customer expectations.
Accordingly our “classic” project planning contained framed time and budget boxes, so called “control accounts”, which the management could use at all times for reliable forecasts to have safe a calculation and planning. We even were able to forecast quite precisely by the priorities when we would be able to submit what functionalities to the business lines for testing, judgement and approval, which in return gave us stability and confidence in development and well-disposed stakeholders for the project.
The achievement: Quick Wins, flexibility and safety
That way we got two achievements: First we could start development without further delays, i.e. without having to wait for extensive detail planning as the standard and the unquestioned basic functionalities in the first development phases (sprints) were already clear and fixed from the beginning. Within five months we had a basic release ready to deploy which covered 70% of the processes and could serve to design the mappings for data migration from the legacy systems.
Second with this approach we kept the “quarrel of requirements” from the team to have it work undisturbed. Since then the discussion was done between the (called today) product owners from the branches and functional departments who needed to agree on a prioritized list of requirements (stories) and define a minimal SOW (product backlog). Later we found that we easily could develop individual market specific enhancements in “country backlogs” around a common core (the template backlog), of which the incremental release was dependent on a proper integration with the core.
Top efficient: agile on development level, “classic” on project management level
During the entire development phase the teams were only bound to what they committed to deliver “ready to deploy” within the 4-6 weeks release cycles from the top-down estimated and prioritized backlog pile. That worked well in 90% of the cases. Development was planned into master schedule and budget as control accounts, risk and issue management closely cooperated with the team leads (Scrum Masters), project manager and quality managers (Product Owners) intensively with the stakeholders.
All in all we could save ca. 2 months of development after 18 months project duration. We preferred to invest this in a well prepared change management in the organization, at the expense of ca. 25% of the initial SOW that showed to be nice-to-haves and rather freed up capacities for new and judged to be more important requirements.
Additionally: We were live with the 14th template release months earlier than originally planned with the final product. Many subsidiaries had their variants already in operation when the initial plan would have started with the roll-out. In total we didn’t save that much on budget side but we won a lot at productivity and business.
An example of Best Practice
Why do I like to tell about this project? Because at that time we didn’t even know that many of our approaches were like today’s agile development methods. And because since then I found in many projects that agile and classic project management do not hurt each other. Coupled right and professional with each other they rather bear high productivity and efficiency potential that would benefit a lot of projects and business cases I see around…