synaigy framework – behind scenes look part 3

In the concept, each sub-project is now described in a way that allows the necessary systems to be tendered, selected and implemented afterwards. The respective concepts are first created system-agnostically – in other words, without pre-empting a system selection. This has the advantage of creating an objective benchmark against which potential candidates for implementation can be measured. 

The concept also lists the overall and project sub-goals as well as the concrete framework conditions, so that the overall picture is always kept in mind for later implementation and one doesn't get lost in individual details and "nice-to-haves". 

In addition, the depicted future processes are captured and made concrete from a business perspective. 

Use cases, user stories and priorities 

By capturing and formulating use cases and user stories, the requirements to be met concretely within the project are detailed. 

Use cases serve here to describe rather technical functions and requirements. They are primarily quantitative, or offer a benchmark for the presence or absence of features in the later map/gap analysis. 

User stories, by contrast, are used for user-centred functions and to describe the expected user experience, and place the emphasis primarily on qualitative design. They provide the benchmark for what makes a good implementation of a feature. 

The features – whether in the form of use cases or user stories – are subsequently prioritised in order to determine their influence on the later selection and, where applicable, the timing of their implementation during the project. 

The relevant part of the specification is made available to potential providers as part of the tender.

Maps and gaps 

Depending on the breadth of the field of possible providers, a shortlist is drawn up to narrow the number of offers down to a relevant set. Care is taken to involve providers with different architectural and business priorities, to enable a genuine choice. 

From the answers to the requirements of the functional concept, a map/gap analysis then produces a score factored by priorities, making a provider's overall suitability for project delivery as objective as possible against competitors. Ultimately, the system and provider get chosen based on the resulting ranking, factoring in commercial considerations. 

Loops, feedback and the way forward 

In agreement between provider and you as client, MVP (Minimum Viable Product) get defined – first part of delivery already offering business value, and a testable, usable product for future users. 

The further features are prepared as a backlog and, based on their order – which is reprioritised again by risk and value – handed over for implementation. 

Through an implementation that follows agile concepts, feedback is gathered from users again and again. This ensures the project is driven in the right direction and improved through constant feedback.  

Multipliers, processes and the trickle-down effect of knowledge transfer 

At the latest with the definition of the MVP, the multipliers gain particular influence: as representatives of the various affected and involved departments, their input is decisive for project success. They can explain progress and decisions to their colleagues who are not participating in the project group. This way, the entire involved areas can gradually prepare for the upcoming transition. 

The background knowledge that multipliers acquire makes them natural coaches for their fellow specialists. They're also the project's ambassadors within the company.