.svg)
.svg)
.svg)
When Top-Toy declared bankruptcy, fingers were pointed at a long-standing and budget-exceeding IT project that was meant to be their salvation. Despite the hardware being ready at train stations across the country, it took several years and budget overruns for the software of the infamous travel card to be completed. IT projects, unfortunately, have gained a reputation for being undersold and consistently running over time.
These IT projects, however, were doomed from the start. Many IT projects are still mired in an outdated understanding of project management, akin to the construction industry's perennial issue of what Bent Flyvbjerg terms "strategic misrepresentation," where planners intentionally underestimate costs and overestimate benefits. Accurately scoping a project requires experienced professionals whose integrity depends on the precision of their estimates. The development of estimates and architectural plans should never be part of a sales process where the likelihood of such misrepresentations is high, as it's often here that IT projects falter. Architectural plans should be crafted by those whose job is to realistically assess risks, thereby creating confidence in the IT project through consistent "de-risking" in the initial phase.
At Kvalifik, we've developed a process to map as many of a project's uncertainties as possible early on, and made it a standard operating procedure (SOP) for initiating complex IT projects. While SOPs might sound bureaucratic and dull, the right process is crucial for ensuring quality. Briefly, the process ensures that the right questions are asked and the right competencies are involved to produce architectural plans that truly map and minimize the risks associated with an IT project.
One of the biggest challenges in building new software is creating the right architectural plans to avoid wasting resources at the construction site - where cost overruns can be especially costly. Therefore, we have a process to ensure the right precautions are taken early in the development process, preventing resource wastage.
Even the simplest IT projects typically contain significant complexity, not immediately apparent at first glance. These complexities are hard to map and discuss, as language isn’t the best medium for topics like relational databases, user flows, or innovative digital features. The success of an IT project largely depends on building with as little waste as possible – that is, with the fewest possible hours spent on unnecessary elements. Therefore, architectural plans for an IT project are crucial, as they provide a language to discuss complexities and a framework for iterating on an idea in the right direction. Good architectural plans make the process cheaper and faster by reducing waste. We have a specific process recipe for what we go through when a partner contacts us about a platform project, enabling us to present them with detailed architectural plans. This process is designed to "de-risk" the project.
The Process Requires:
• An account manager to facilitate meetings, delegate roles, create agendas, take notes, and facilitate the development of User Stories to uncover the platform’s complexity.
• A technical consultant to discuss technical challenges and create models for understanding the platform's technical complexity, like an ER-diagram and an initial data model.
• A design consultant to discuss UI and UX insights and create models for understanding features or user flows, primarily through low-fidelity sketches.
• A developer willing to play "planning poker" with the technical consultant to provide a project budget framework.
• A collaborative whiteboard tool. At Kvalifik, we use Miro, but many similar tools are available. The process involves six phases, each facilitating the right learning journey, in our case, for both Kvalifik and our partner.
A whiteboard workshop aimed at mapping the platform’s user types and as many User Stories as possible. Both Kvalifik and the partner participate. A User Story is an excellent educational tool to ensure everyone understands each other and incorporates the software's users into the functionalities from day one. A User Story is defined by filling in the blanks in the sentence: "As a {USER TYPE}, I want to {ACTION}, so that {DESIRED OUTCOME}".
Participants: Everyone.
Outcome: Foundation for understanding the platform's actual features through the first iteration of User Stories.
Desk research where the account manager, technical consultant, and design consultant review all User Stories, possibly add new ones, and create low-fidelity sketches of the User Stories identified in the first workshop.
Participants: Account manager, technical consultant, design consultant.
Outcome: Low-fidelity sketches and second iteration of User Stories.
A whiteboard workshop to review the sketches and User Stories uncovered in phase 2 and gather feedback. Together with the client, we review the platform from start to finish, come up with new User Stories and ideas for flows, and reprioritize all the platform's features based on our hypotheses. Almost every time, something fundamental about the platform is rethought in this phase, simplifying and reducing the resources needed to build it.
Participants: Everyone.
Outcome: Feedback on sketches and User Stories, and reassessment of the platform's hypotheses.
Desk research repeating all activities from phase 2. Additionally, the technical consultant sits down with a developer to play "planning poker" based on all known User Stories. The goal is to dissect platform development into epics and provide an overall estimate for each epic. An epic is a collection of tasks that make up a feature, solving one or more User Stories. At this point, the platform's overall data model begins to take shape, and the technical consultant develops an ER-diagram to visualize the technical complexity that can be difficult to discuss otherwise.
Participants: Account manager, technical consultant, design consultant, and developer.
Outcome: Last iteration of User Stories and low-fidelity sketches of the platform, an ER-diagram, and epics with overall estimates, allowing for an accurate project budget framework.
A closing meeting where we review the architectural plans developed along the way. This includes the epics we've developed and the resulting budget framework.
Participants: Everyone.
Outcome: Architectural plans for the platform project, consisting of the above-mentioned User Stories, low-fidelity sketches, ER-diagram, and epics with overall estimates. Together, these architectural plans ensure that subsequent development of the platform will deliver value by fulfilling the project's main objective.
A retrospective meeting where we internally at Kvalifik review the process and consider what we can do better next time.
Participants: Everyone except the client
Outcome: Continuous improvement of our SOP.
The process takes a maximum of one month and provides an overview of the major uncertainties associated with digital platform development by mapping the fundamental hypotheses about the project. Once the six steps are completed, you have the right architectural plans and the necessary knowledge to develop a larger digital platform without wasting resources.
Happy IT de-risking!
