Once we’ve established objectives and key results for a project, we take a more granular view of how to achieve them. To do this, we use business models and technical models that help us understand your business as a whole, the current systems in place and any work completed so far. The models allow us to start plotting a journey that will eventually become a fully-fledged roadmap.
By the end of this process, we have an idea of how big the development project is, the level of resources required to complete it and the steps we need to take to achieve it.
The Importance of Modeling
Modeling helps us overcome any miscommunication that may have occurred previously and get specific about the work. The simple act of talking through what’s required and how we might achieve it gets everyone on the same page and uncovers issues that a client may not know they have.
A lack of communication and subsequent misunderstandings is one of the main reasons projects fail, according to The Agile Business Consortium. “Modelling techniques are designed to improve communications and prompt the right questions. They provide an early means of checking that the solution being developed is what is required. They are a valuable aid to achieving project success.”
Models also aid our discovery process. It’s rare that we’ll come into a project without the organization that hired us already having attempted a solution on their own. For that reason, we rely on models to understand the existing situation and the technology currently in place. Models are indispensable in this regard, says Marc Lankhorst, managing consultant and chief technology evangelist at BiZZdesign. Code alone isn't enough to understand a process; we often need input from existing developers or analysts to understand the context, too.
It’s also a matter of efficiency. By understanding existing business processes and technical solutions, we’re able to avoid wasting time and resources going over things twice or implementing new solutions that may break what’s already there. These kinds of mistakes are common in development. They’re costly, too, both in terms of the resources required to fix and the delivery delays they cause.
Our Two Models: Business and Technical
At Kingsmen, we use two types of models to guide our development projects: business modeling and technical modeling.
Business modeling is about understanding your business as a whole and the specific processes and workflows used throughout the organization. At this stage, we’re mapping out how the new software project will integrate with the existing business and in what way it will help to achieve the key objectives and visions we’ve already outlined.
It is critical to look at wider business processes when developing a new software feature, because, frankly, many organizations do not have a complete understanding of their existing processes to begin with. There is often a disconnect between what developers and analysts are doing on the front lines and what executives think is happening. Business modelling helps us clarify communication and increase efficacy across an organization's hierarchy.
Case in point: On a recent project with a finance company, stakeholders weren’t aware of how manually intensive certain processes were until we listed everything. When they did, they prioritized the automation of these processes to make their employees' lives easier. If it weren’t for our team mapping the step-by-step processes already in place, we wouldn’t have flagged this issue and it would have continued to be a significant inefficiency to the team.
If business modeling takes a 10,000 foot view of the project and accounts for business goals as a whole, technical modeling zooms into the work. Technical modeling establishes a detailed approach to software development based on the existing technical environment, processes and people.
At this stage, we start to lay out exactly what it will take to deliver the project step-by-step. We take stock of any existing work on the project and the software currently in place before using the vision and key objectives as our guide to detail what needs to be built and when.
There’s a future planning element to our technical modeling, too. When mapping out the technical requirements of the development, we spend time thinking about how technology may change in the future as well as how technology needs may change as the business scales. There’s no point in building something that solves an immediate need if it becomes outdated 18 months after being implemented.
The process isn’t so much about building a step-by-step guide on how to get to the destination as much as establishing what that destination will look like, writes the editorial team at intelligent diagramming application Lucidchart.
Part of the reason for putting more focus on the end destination rather than the directions to get there is because directions are likely to change in the future as new features are requested and goalposts are moved. It’s also why both our business and technical models lean heavily on the concept of agile modeling and continuous improvement. The agile model “provides the developer with an understanding of what he or she will develop, writes Kate Eby at work execution platform Smartsheet. “Simultaneously, it provides the stakeholders with the same picture, which they can examine to ensure that the end goal meets their needs. This allows for rapid feedback and incremental updates throughout the process.”
Client Interaction Is Vital to the Success of Modeling
Both business modeling and technical modeling may sound like part of the core development work that we undertake alone, but it’s vital to work in partnership with the client at both stages.
This is another area where the time demands of multiple people throughout the organization make our Working Partnership Agreement so important. Both business modeling and technical modeling require the input of leaders throughout the organization to consult on existing processes and best practices going forward.
There’s an additional reason we work together with clients on this. When they are part of the modeling process, they take ownership of the models. We may be the ones drawing on the whiteboard, but because the employees are providing the information they need, they play just as important a role in their creation as we do. We’ve found that when employees own the models, they’re much better at communicating both the business and technical aspects to stakeholders across the organization and getting the buy-in needed to proceed.
Agile Modeling Not Waterfall
It’s important to remember that because we take an agile approach, the modeling we create at this stage won’t be complete or unchangeable. We return to every stage of the planning process periodically throughout the development to update models or our roadmap where necessary.
This is unlike a traditional waterfall methodology, where full documentation is created before any coding starts. This approach results in long, detailed documents and the entire process to production can take several years to complete, writes Isaac Sacolick, president at StarCIO.
While we do complete much of the process-based work before getting started with the development, we never let models become more complicated than they should or impede the development of our work breakdown structure — the final piece of our planning puzzle.
Images by: ThisisEngineering, Redd, Leon