Strategic software investment: Maximizing returns through effective kickoffs

You can trace most problems in software projects all the way back to the start. Maybe there was a large PDF of needs and requirements. A project kickoff meeting or call that had everyone nodding, but no one asking any questions. A set of goals for the project, but no understanding of how they support the goals of the business.

Any kind of software, app or website project involves three groups of people. You have the business team, who is asking for something to be done. You have the delivery team, the developers and the designers who are being asked to do it. And then you have the end users, who will be using it when it launches. It’s rare for a typical project kickoff meeting to include all three groups, and even rarer for the groups to talk to each other effectively. And that’s why projects fail. The business side will throw a big, long PDF over the wall to development. Development will try to read between the lines to decipher what to do. And neither side will get input from the end users to find out if they’re really building something silly.

We knew there had to be a better way. So years ago, we started asking our clients to give us two days of their undivided attention, leaving their fishbowl to come into ours for an Inception. The purpose was to get all three sides represented for a deep-dive into the client’s business, its needs and its capacity, so we could then determine what a project should look like. Because we’ve done these complex engagements so many times before, we’re able to ask questions that companies maybe haven’t even considered, but we know are crucial. We suss out what the scope should be, where the risks are, how we want to put together a team and how long it should take.

It’s an exciting two days that prevent many frustrations and misunderstandings and ultimately save our clients time and money.

Why Inceptions give our clients more value than the average project kickoff meeting

We’ll never know less about a project than we do at the start. But an Inception is an opportunity to make sure everyone shares a common vision. Instead of relying on assumptions, we can prod and question and validate as much as possible to come up with a shared understanding. Here’s our checklist of goals for an Inception:

1. Determine whether a project makes sense

The best thing an Inception can do for our clients is keep them from wasting money. Sometimes we’ll spend two days in the room, figuring out the scope, cost and duration of a project, only to realize it’s not going to be ROI positive. That’s a phenomenal outcome. If it sounds like a failure, think about the alternative. Our clients can stop the project with that discovery, and they’re only out two days, rather than months of design and custom development.

Other times we’ll recognize that based either on the money or the desires they have, it doesn’t make sense to go the custom route. Instead, they should take an existing product off the shelf. It’s kind of weird when you think about it, for a custom development company to tell people not to build custom software. But that happens. Our job in the Inception is to help the client find the best way to achieve their goals. That doesn’t always mean finding a way to create more custom software.

2. Decide if TXI is the right partner

That can extend to realizing that we’re not a good fit. Neither side wants to be locked into a six-month contract only to realize two weeks in that things aren’t clicking like they should be. If we’ve never worked with a client before, we want our first engagement to be something small. An Inception is a great introduction to new clients. Eventually we’ll build software. But an Inception lets us build a release plan first.

3. Develop a shared language

Words are super slippery. We need to define them. We’ve had clients write great documents explaining everything perfectly, but designers, software engineers, and end users can all interpret them differently. This is even true between stakeholders. By asking questions in an Inception, we’ll sometimes find that people who thought they were on the same page actually meant completely different things. We use a lot of facilitation techniques to translate prototypes and business processes into sticky notes and index cards so we can quite literally get everything out onto the table. By the end, we’re able to create definitions so we have the same level of understanding and can talk about things the right way.

4. Get feedback from strategists, designers, and engineers

The eventual goal of any software project is to have everyone working together on building the product. We just think that should happen in the envisioning stage too. Instead of a client meeting with only me or another member of our team, an Inception gives them a chance to actually meet with the team who is going to create their product. Our integrated team and can sit with them and say, “I hear what you’re saying, but that’s expensive, have you thought about this?” Those tips save us time building a plan that doesn’t take the realities of execution into account.

5. Ramp up quickly

After an Inception, we’re ready to go. There’s no game of telephone. You’ve already actually worked with the developer or designer who’s going to solve your problem. We know you and how to communicate with you, and you know the same. It makes it that much easier to jump into a project and get started.

Want to start visualizing your project risks? Download our free Software Risk Management template.

How to lead an effective Inception

During the two days we’re running an Inception, we ask for undivided attention from our clients. It sounds like a burden, and clients often balk, but we know it’s the fastest way for us to deliver the most value to them.

The agenda starts with homework — which no one ever wants to hear. But to get all the understanding we need in just two days together, everybody has to bring some ideas to the table. We ask clients to think about their users, their goals and a few other big-picture things before they arrive. This gives us guidelines, so we can start digging into their ideas, instead of teasing them out.

We use a lot of facilitation techniques during an Inception to turn these initial thoughts into a plan. One we often use is to force rank objectives based on their importance. Everything requires resources, so if the resources are fixed, there will be tradeoffs. We need to know what can fall by the wayside or wait until a later release. To get those answers, we’ll also help clients create ROI models. Then we build out business process models to understand what we’re going to build, how we’re going to automate things, what the application needs to do, etc.

Once we have the basics, we move into prototyping a potential product. We almost always keep it very lo-fidelity, often just using Post-it Notes. While it’s murderously painful to watch somebody do business process modeling in Visio, it’s very easy to do that on a Post-it Note. If I get something wrong, I can tear it up, rewrite it, move it around. Post-its also lets us see where the notes about difficulty or bad user experience are piling up, so we can flag those as problem areas. At this point, we should probably invest in 3M stock.

After we conduct an Inception, there’s usually a one-to-two-week gap where we synthesize the findings and develop the deliverables, detailed below. Sometimes we’ll also use this time to look at an existing codebase or API, or to do a code spike to test out how something is going to work so we have a better sense of what our estimates should be.

What Inception deliverables look like

There are two types of Inceptions we do now. In the first, a client comes to us not quite sure what the next three years of their company’s technology will look like — what to keep, what to build, what to buy. So we help them figure that out with a Roadmap Inception. In the second, a Product Inception, a client comes to us with an idea, and we help them think about the functionality, users and goals of a specific application or website. They have slightly different facilitation techniques and slightly different outputs, but the idea in both is to use our two days to figure out how technology can move the business forward with the least risk.

With a Roadmap Inception, we set a course for the future

A Roadmap Inception leaves clients with a release plan that tells them which projects to tackle in which order, and which technologies they may want to hold off on or avoid altogether. To get there, we break out all the things the business does. For example, a photography business has to both attract and retain photographers and sell clients on their services, among other functions. For each function we identify, we’ll lay out all the ways we could improve that process. Then we make decisions about which improvements to tackle in what order based on risk vs. reward.

Whether or not they decide to move forward with us, the technology roadmap is an incredible presentation to unite stakeholders on a strategy. And while it doesn’t go into detail on specific features or difficulty estimates for each function, it does deliver a big-picture template they can follow for their future tech.

With a Product Inception, we develop a plan and estimate for the project launch

A Product Inception is much more narrowly focused but also more detailed. Because we start knowing exactly what project we’re tackling and why, we spend our time breaking the project down into stories, or tasks that the finished product will have to accomplish. Then we assign each task a priority of low, medium or high. We also determine the possible risk based on how difficult the task is and how many times we’ve done it before. Once we know priority and risk, we’re able to group those tasks into releases and develop a proposal that best matches our client’s capacity to the requirements that need to be met.

The way we handle risk is especially interesting. Instead of making a guess at the exact difficulty of a task, we assign it a range. It’s a great indicator of risk. The wider the variance, the more risk you might have. So we’re able to look at different functional areas and if, say, a search has a huge range in difficulty estimates, we can poke into that and do some prototyping or a short coding experiment called a “spike” to see if we can learn enough to reduce some of that risk.

The final product is a release plan that contains all of the stories and features, their risks, and their priorities, as well as the costs and the capacity of our team members. That allows us to rapidly and transparently model several what-if scenarios (“What if we cut low-priority features from the scope? What if we add another developer pair? What if we reduce the timeline by two weeks?”). This allows us to play around with various constraints (time, scope, budget, team size) to collaboratively shape the release plan.

We believe in radical transparency at TXI, and think that exposure to risks and timelines should happen at the outset. A Product Inception allows us to be completely open about what things cost and how long we expect them to take. And from there, our clients can look at the ROI and find ways to cut costs and/or risks and increase opportunities.

It starts with a meeting

No matter how you start an engagement with TXI, we’re always scoping, estimating, prototyping, testing, validating, and understanding if the solution we deliver is the right one from the start. In this process, you’ll learn a lot about your technology, your users, your product, and yourself.

Want to know more about what an Inception looks like? Contact us to get sample homework questions to get you thinking about your next project.

Published by Strategy Team in Process

Opportunity Accelerator

Blog

Strategic software investment: Maximizing returns through effective kickoffs

Blog

Top “product smells”: A primer on assessing product performance

View more Insights

Let’s start a conversation

Let's shape your insights into experience-led data products together.