The Importance of Unified Concept Planning for IT Projects
STRG understands the challenges you face as a forward-looking, ambitious change leader in your company. You are looking for an IT partner who understands the technological challenges for the 21st century’s fast-moving marketplaces, data structures, organizational flows and strategic goals.
We will support your organization through every step of your project, from idea to product and beyond, by:
- creating a strategic concept;
- onboarding all stakeholders;
- defining targets and KPIs;
- integrating design ops and development ops;
- creating modular implementation structures;
- rolling out the product(s);
- assuring efficient operations; and
- continuously adapting to technological advances.
You need an IT partner that not only can implement a plan, but can help to create a unified digital business concept that suits your immediate and future needs.
We understand such challenges because we have worked through our own and we have successfully helped our clients understand and conquer theirs. How do you approach such ambitious projects? What are the qualities and experience your team needs? How can you trust that your partners are on your side and have the necessary experience?
STRG won’t just build your IT project – we’ll help you build your business.
This article dives into the details about how we help our clients plan and execute a concept, from A to Z. If you have the time, read on. Of course, we’re also happy to tell you all about it in person. Contact our CEO, Jürgen Schmidt, to start a discussion today!
STRG has the expertise, talent and insight to help your company dive deep into its digital-concept strategy. We practice the most modern Agile methods for managing and implementing a project. By putting your strategic planning, design, and development under one roof, your IT project is more likely to succeed, less likely to be derailed by mission creep, and you will be able to set both ambitious performance targets and realistic budget expectations.
Since 2008, our method has been to guide our clients through an integrated concept and implementation process, providing a clear understanding of how their needs can be matched up to their dreams.
We will help you understand the reason why, the way how, and what will be gained.
7 STEPS TO A CONCEPT:
- Get key stakeholders to agree upon a clear reason why.
- Define clear primary and secondary targets.
- Set KPIs to measure targets.
- Plan and develop in modules and microservices.
- Make the rollout plan simple (MRP before adding secondary features).
- Get buy-in from all teams and use their intelligence/creativity.
- Establish a permanent conceptual phase: never stop during or after a project.
TYPICAL CHALLENGES YOU MIGHT ENCOUNTER
All too often, well-intended IT projects become derailed or don’t meet expectations. This comes at an enormous price to a company, in terms of lost time and resources, as well as shattering the morale of its stakeholders and staff.
There are many reasons why an IT project can fail during development and launch, but a common reason is that it lacked a solid, unified, underlying concept from the start – a concept that answers the question: “Why?” If there is no consensus among the company’s top internal stakeholders, its diverse work teams, and its external contractors, before a plan for how is defined, the result is likely to fail.
Many IT consultants will charge a client high hourly fees and require countless hours of meetings to create an IT project concept, only to hand over its implementation to the client’s internal or outsourced designers and developers. What then often happens is that the concept’s goals meet the sober realities of implementation. When the implementation teams are not working on the same page, without a common understanding and acceptance of the original concept, things tend to go badly. Mission creep, budget overruns, poorly conceived content architecture, launch delays, and internal turf battles are only a few examples of bad outcomes.
Likewise, there are IT developers who bill a client by the hour to implement a project concept plan that they took no part in creating, only to disappoint the client later on because the concept was flawed from a budgetary or technological perspective. Or, worse, they deliver a product that does not accomplish the concept’s goals, meet its performance targets, or satisfy the end-users.
STRG isn’t just a consultancy or a build shop – it’s both in one, and more! STRG helps you build a solid strategic concept and develops only what your company really needs. STRG helps you to create a strategic concept, as well as coordinate your project’s design and development.
By combining it all under one roof, STRG is at your side from the beginning through the rollout, communicating efficiently with all stakeholders and staying within a practical and predictable budget framework. Every cent spent on your IT project will be an investment in your digital future, not money thrown down the drain.
GETTING TO UNDERSTAND WHY
When you come to STRG with an IT project in mind, the first thing STRG asks you is “Why?” It’s important that you take the time and effort to know why you want to do this and what you want to achieve by it. The core concept is defined by the answer to “why?” — and if that concept is not shared by all the stakeholders, designers and developers on your IT project, it will not proceed smoothly.
“All roads lead to Rome,” says STRG’s CEO Jürgen Schmidt. “You have tons of possibilities to solve a problem, but we need to find the right way for each specific client, and this is only possible when both of us understand the reasons why.”
In order to help you to create a concept, STRG will lead your key stakeholders through a kickoff workshop to discover the real answer to why you need the project. “Sometimes clients will answer, ‘because we want to increase our revenue’ or they’ll simply recite their official vision statement,” says Schmidt. “But I tell them these are not valid reasons. Every company wants to maximize its profit; however, customers don’t buy what you do, but why you do it. Revenue is the outcome, the side effect of producing value for the customer.”
Although a company’s stakeholders might believe they share the same reasons for investing in an IT project, STRG’s kickoff workshop will often reveal dissent among the key stakeholders. “At one client’s workshop, I asked the 20 or so participants the ‘Why’ question. Their immediate response was: that’s a stupid question, everyone knows what we are and why we exist.” Then Schmidt asked them to give their individual answers while he wrote them down on a flipchart. “A few hours later, I had written down two dozen completely different opinions about why the company should embrace digital innovation in the future!” A potential disaster averted!
Another client came to STRG with an existing “strategic concept” that it had already developed and split up into separate implementation projects – social media, direct communications, website, back-end CMS, system architecture and content architecture. “The CEO told us he had already communicated the strategy to each respective stakeholder, asked them to work independently to create each sub-concept, then come back after a year to knit it all together into a master plan,” recalls Schmidt. “I had to give him the bad news that this would never work out – each team was going in a different direction and there would be no feasible way to bring them all together.”
DEFINING AND MEASURING PRIMARY AND SECONDARY TARGETS
Only once STRG helped this client to agree upon its core, primary targets, the project could be split up into smaller target-oriented teams – each yielding its own secondary targets that still adhered to the core concept.
The required number of strategic concept workshops can vary – as well as which stakeholders take part – depending on the company’s size, budget and existing team structures. Sometimes, particularly stubborn and intransigent internal stakeholders might be excluded at this stage, because they feel threatened by change and can disrupt the envisioning process. “Fear is the worst advisor,” believes Schmidt, but sooner or later, their buy-in will also be necessary.
Once the primary targets have been set, STRG then lays out methods to measure their eventual success. KPIs are defined, as well as various tools for measurement. With these methods already in place, each step of the journey can be evaluated and wayward efforts can be caught and managed early enough on – before they can ruin the whole project.
The concept, its primary and secondary targets, and the performance indicators are then all laid out in a strategic concept paper, which will be a “bible” for the entire project and helps the client with a successful onboarding of its work teams. It also helps STRG determine the resources it will need for implementation, allowing it to make fair and predictable cost estimates.
WHERE CONCEPT MEETS DEVELOPMENT
In some cases, a client has already gone through its design ops phase – the art direction and graphical UI plan. This can be a make-or-break scenario: If the design concept was created separately from the rest of the project – for example, if a design previously purposed for offline content is expected to fit digital requirements easily – it can derail the hard-won, unified project concept.
“The best-case scenario is when a client lets our experts to handle both design and development,” says Schmidt, “but when a client insists on using their own designers, we insist that they need to be part of the original project planning, otherwise the project rollout will run up against hurdle after hurdle and require more time and budget resources.”
The client must be made aware of the 80-20 “Pareto” principle – 80% of the project is completed with 20% of the human and budget resources, while the remaining 20% requires 80% of the effort. If the design ops and dev ops are not working in tandem – the front-end UI designers understanding the possibilities and limitations of the back-end developers, and vice versa – this effort-to-output ratio increases.
THINKING IN AGILE MODULES
Once the design ops and dev ops are on the same basic page, “our master plan is carefully divided up into modules,” says Schmidt, “in order to define action steps and backlogs that accomplish the primary and secondary targets.” These modules might be split among the client’s internal work teams, outsourced contractors and/or STRG’s own staff, which consists of experts who can handle all aspects of design and development processes – from graphic designers, data scientists, backend and frontend developers, systems architects, and content specialists.
Sometimes, the modular plan can be diagrammed totally offline, using pieces of color-coded note paper laid out on a pin board – each one describing a different module or backlog issue. (It may seem ironic for a tech company, but sometimes analog methods work the best!) Each piece of paper represents a module, a requirement, and implementation phase… “Here is the comment system, there’s a rating system; here’s an image gallery, there’s a little piece of content or a long-read article; here’s an upper connector, and so on – all separate modules,” explains Schmidt. “For the rollout of the first MRP [minimum reliable product], we need to, for example, publish one article, attach images/video… Looking at the backlog, you can define implementation phases and plan in an agile, modular way from the get go.”
STRG’s internal teams work with modern Agile/Scrum methods, “which fit perfectly with a modular development process,” says Schmidt. “Sometimes, though, a client expects everything at once, but we say, sorry, no – you can dream about it, but it won’t work out.”
Agile project management allows for a non-linear development process. Whenever a stumbling block between dev ops and the master plan occurs, an Agile process permits STRG to loop back to the original stakeholders, unit heads, designers, editorial team, marketing department, etc., then back to the developers to work out a practical solution.
KEEPING IT SIMPLE
Many clients will start to get creative once deeply inside of the project development phase. “One of our clients decided, in the middle of the project, to add a secondary feature,” recalls Schmidt. “They wanted to publish recipes with a user rating system. It was just an afterthought that sounded simple enough, but the technology required to implement it would have broken the budget. When we looped it back to the client, it turned out that this feature was only an off-the-cuff idea from the content architecture team and not at all central to the project’s mission.”
In other cases, however, an unplanned feature might be valuable enough to implement after the unified plan has been agreed to. “When we worked with the Austrian automobile-club, ÖAMTC, their travel agency arm discovered that without access to their member data, they wouldn’t be able to market various travel offers to the membership base,” recalls Schmidt, but GDPR (data protection regulations) limited how such data could be shared. “It became a huge process to link the back-office SAP system to the front-end – although it was not originally a project target, it became worth the extra cost and effort to implement and helped to eventually increase their turnover threefold.”
Whether a client demands too many possibilities from the outset or an onslaught of features emerges during development, STRG believes it is important to keep things flowing from simple to more complicated modules. For example, it makes no sense to develop a reader comment system before a site has earned enough visitor traffic. Priority must be given to services that build the traffic to begin with. If a client wants to launch every feature in one big bang, it won’t have anything to communicate later on, and if only one feature is not working smoothly, end users can easily dismiss the whole project.
Echoing the modular concept, modern system architecture benefits from splitting up specific features into separate microservices, each with its own API and database architecture. This enables individual modules to be launched, tweaked, swapped out or removed independently, without affecting the entire system’s business logic, as is the case when a monolithic architecture is developed. If there’s any problem with one microservice, it won’t take down the whole site.
CONCEPT WITHOUT END
In the end, there really is no end. A project concept must always remain agile and adapt to evolving technology innovation and user needs. Conceptual planning should never be thought of as a one-time “been there, done that” event. Throughout a project, and beyond, the concept process should become embedded as a permanent, measurable business methodology. The answer to the question “Why?” should be a guiding star, but not an eternal truth.
Feeling inspired? Have you got a few questions? Contact our CEO, Jürgen Schmidt, to start a discussion today!
- Call STRG's CEO Jürgen, or write a mail juergen.schmidt@strg.at Mobile: +43 699 1 7777 165
