Hi,

Today I wanted to talk about Middle Out project management, in future blogs I’ll talk about Organizational fit, and Diamond Project Management (NTCP) approaches, but today is reserved for middle out project management.

This is something that evolved on it’s own as I sought ways to help manage a project that had been running unsuccessfully at client for over a year, it didn’t of course jump out, and only after actually implementing it, did I start researching the topic to further help substantiate the approach, and learn from those who had gone before. An excellent case study was written by Audrey Crane in 2006 http://www.dubberly.com/articles/middle-out-design.html and she also made some slide shares to go with it that you can find on google.

When I first arrived at the client, it became obvious that a lot of time and effort had been spent on analyzing and designing the solution (ERP system) that they wanted, however as I started reviewing the documents, it also became clear that various people had worked on requirements gathering, analysis and conversion into design documents which unfortunately did not clearly describe how the system should be built. Having spent significant amounts of time (internal resources especially) and money (external resources), it was clear the organization did not want to throw away the work done, but try to ‘tidy it up’ and salvage what could be from the build that had taken place.

I decided that the best approach would be to try and catch and fix the bugs as they appeared during the remaining stages of testing & deployment, hoping that the build was not too far away from the original requirements, but as we got closer to go-live, it became clear that I was trying to catch a falling knife, and a sharp one at that. The system had been built by too many people, working on very specific parts of an overall system, and this resulted in an extremely disjointed system that was held together by a patchwork of code written in mid-test just to stop it all collapsing. It also became apparent that the logical foundation behind the original concept was not as strong as one would hope, and in fact was much more focused on a data warehouse & reporting model than an ERP system.

All this led me to the conclusion that we could not start over with a new detailed design phase (top down – traditional approach), now having gone live in one country, and on the brink of switching on the next, but that working to continually patch and hold together a new system (bottom up approach) was never going to work effectively. Switching on a system that is ready to fall apart is not a great feeling, and one that needs to be justified in the wider context of the entire organizational journey and learning curve that needs to be built within the company.

The logical approach then was to try and rebuild the conceptual foundation of the ERP system, based on an ever greater understanding of what the organization was trying to achieve, but try to use a rapid development or agile approach to building a new version of the ERP. This meant reducing the team by a third, replacing some of the members with stronger, more experienced team members and changing the way development would work. We started working in small teams of business users, developers and consultants to ‘own’ and ‘deliver’ significant portions of the system (ie. Sales, Assets, Purchasing etc.)

Because we no longer required very detailed design documents, and removed a lot of the formality in moving from analysis to design to build to test, and we had the developers sitting with the users & consultants, we could very quickly adapt and adjust the system to meet the requirements of the business. Interestingly, it also became very clear that without this middle out, or prototype approach, we would never have been able to fully gather the requirements anyway. There are so many variables in building an ERP system, that you simply cannot capture this all before you’ve even started prototyping.

The middle-out project management approach has been a fundamental change in how the project operates, by having small, empowered teams, working on specific areas of the ERP, and going through repeat prototypes with dedicated business users, we’ve been able to significantly increase the delivery times, and more importantly all the participants (business users, developers and consultants) are bought into the process, and see the benefits this approach brings, it also significantly reduces the final testing required, as this is all part of the new approach.

Whilst I remain a strong advocate of a proper analysis & design phase, rapid, repeat, prototyping is something that every project needs, and based on the organizational context, and NTCP analysis of the project (see diamond project management approach) using a middle-out approach – even going so far as to change the way the project is run once you get to the build stage, seems like something every project manager needs to have in his toolkit and on his radar, it has definitely helped frame how to manage and solve the problems at this major client.

As a final comment – your progress reporting needs to be adjusted to suit middle out project management. Since you are departing from the classical approach, you cannot easily track during the build phase where you are anymore, so you’ll need to ensure you have systems to help track this better than in the standard project management approach, and adjust your reporting to give your customer confidence that you are delivering on target.

Feel free to leave comments or drop me a note if you would like to discuss middle out project management further.

Martin