Over the years spent in systems integration and business process automation we have experienced and encountered a number of varying project models. I'll give a brief overview about some of the most intriguing project models used in the integration business.

 

Totally wasted - model. This one's really simple. Requirements are being specified and given to integration vendor who starts the development work. Development might or might not reach the end but at some point business owner notices that all the ordered integrations and interfaces are totally useless. All the development efforts so far are totally wasted.

 

Fools rush - model. "I need solution and I need it yesterday." All the specified integrations are prioritized as top most priority and there's urgent rush for getting things done. Go-live deadline is the authoritative issue – even though it has been decided ages ago before any concrete details about use cases. There is no knowledge about any functional or technical details but full blown implementation work is undergoing. Finally development is completed but integration does not work and no one knows what it actually does or should do.

 

Bend over backwards - model.  Again a very very simple model. Project is first implemented and then designed. Afterwards it is clear that initial assumptions were completely wrong and project was started with wrong artefacts.

 

Teach your grandmother to suck eggs - model. The one who possesses most expertise from past integration projects is not being listened but business owner demands to execute project as he knows it must be operated. When carrying out the project nothing seems to go smoothly - all project stakeholders get really frustrated because of all the setbacks and delays. Finally voice from the experts gets through and things start happening - although this could have been avoided in the very beginning.

 

Megalomania - model. Everything is renewed, refactored, upgraded and rebuilt at the same time starting from product line to business processes. ERP, CRM, material management, finance and payroll systems are all undergoing serious development in parallel and all the integrations between them are needed to develop from scratch. No one actually knows how the processes should work and what kind of automation is needed – line-of-business system vendors and kept in blind from any external disruptions. Functional requirements for LOB system interfaces don’t match and have big contradictions. Integration work required to do is approximately few man years of work and three weeks of calendar time has been allocated for it. Finally when the project should be ready nothing is accomplished.

 

Mad as a hatter - model. Everything is a big mess. Overall architecture is not being paid any attention - the who shouts the loudest get's his voice heard. Business units have more and more exotic requirements and demand them to be implemented as soon as possible. Project organization is being restructured every month and key contact persons change always after few weeks. Some subprojects are being ordered and after few days they are cancelled - often project scope is totally different what it used to be a week earlier. Workshops are being scheduled but actual business owners don't show up in the meetings - vendors do not have a single clue what is being expected from the business owner. Huge amounts of money are being spent in projects where actual deliverables are really trivial.

 

Cream of the crop - model. From the start everything sucks. Existing business applications suck because they are being used in a ways that it's hard to even dream of. The "existing" interfaces suck big time – they don't work or no one knows how they should work. Use cases suck because there isn't a single person who understands them. Integration vendor has a hard time first to understand what is needed to do and then to figure out is it even possible to create a solution based on perplexing requirements. Really hard work, long days and all the skills available are needed to get things done. Eventually if the solution somehow works no one actually understands that project was categorized as a mission impossible.

 

See our way of working at icc.frends.com