“Let’s Just Get Started and We Can Figure Out the Details Later”

Have you ever had a bad feeling about a project before a single line of code was written?

Your company is competing in a fast-paced environment. Your clients are demanding, and time is in short supply. The business side is pushing to get going on a project. While you want to be a good partner who helps the business “get stuff done,” experience tells you that you’re just not ready.

How can you be responsive to the needs of the business? Why don’t your business counterparts share your concerns?

The Situation

Kenton is a product manager for a midsize health insurance company. While growth has been steady for many years, the competition has recently become fiercer, and the landscape is changing. After meeting with some of his top customers and salespeople, Kenton and his team developed a strategy that required a completely new set of offerings. Excited that his team identified potentially game-changing features, Kenton immediately heads over to Ryan, the application development leader. Time is short, and Kenton wants to release the new offering before open enrollment next year.

The Face-Off

Kenton: Ryan, as you know, thanks to new competitive challenges in the market, we’ve been struggling with our current product. I just met with the executive team, and they’ve agreed to give me the budget to enhance our broker policy selling system.

Ryan: Wow . . . interesting. What does it look like?

Kenton: The main idea is that we will offer our brokers a tool that enables them to offer our policies right alongside our competitors’ policies. We’ll provide key information about the differences between the policies, along with a price comparison tool. Then, through a white-label website that carries their brand, their customers can purchase the policy of their choosing right from our website.

Ryan: I can see why this can be a huge win-win.

Kenton: Right! Instead of having brokers act as middlemen, the tool makes them an extension of our company. It will enable them to sell more of our policies and make a consistent margin on our products. We will offer price incentives for policies sold through the tool. They can do this one by one or in bulk for deeper discounts.

Ryan: I see the benefits, but this is going to be a huge undertaking. When will you get the green light to move on this?

Kenton: We have all the approvals and are moving full steam ahead. I emailed you an overview doc. It should give you what you need to get going.

Ryan: Well, first we need to identify all of the business stakeholders and schedule some time to make sure everyone is on the same page with what we’re trying to accomplish and by when. I would also like to get a better understanding of how all of this will work in terms of client value.

Kenton: I hear what you're saying, but we don’t have time for that now. Let’s just get started and we can figure out the details later. Let’s work on getting your team ramped up.

Ryan: Look, I know how this goes. My team will interpret the business intent based on the information you sent me. We’ll get way down the path, and then you’ll figure out that what you originally sent me isn’t what you actually need. You’ll start asking to change things. Then my team will be on a death march. I will take the heat, and if I survive that, I’ll lose my best developers. If we are going to do this, we need to do it right!

Kenton: Ryan, this is our number one initiative now. We have to get started! We will be collaborative and can run this in iterations or whatever you want. That way we can just focus on what we need for the iteration.

Does this sound familiar?

Has a business sponsor ever asked you to “just get started and we’ll figure it out later”? If so, what they were really telling you is that they’re not quite sure what they want and they don’t really have the time to think it through.

Beware! This is an exceptionally tough spot and one of the most dangerous times to start a project—especially with a key initiative like the one Kenton described. You can’t say no because you want to be a partner to the business, but saying yes can be just as dangerous.

Having alignment and a clear understanding of how project success is defined is critical. If you’ve ever been involved in a project that failed to meet business expectations, you probably agree that it is better not to start at all than to start with ambiguous objectives and requirements.

The Resolution

Ryan: That’s all fine and good, but unfortunately, it doesn’t ensure that you’ll get what you need by open enrollment. It might seem like I’m being stubborn, but I assure you that’s not the case. This is as much for me as it is for you. If this is really the number-one initiative now, then people should be able to find a way to fit it in a requirements session.

Kenton: But won't that take forever?

Ryan: I won’t let that happen. We need to get all of the right people in a room and aligned on what success really looks like. I’ll bring in a facilitator to help us keep moving. It should only take a week or two if we can stay focused.

Once we have a good plan in place that we all believe in, we can run short iterations and focus on high-priority feature sets first. This will help us do status updates with stakeholders along the way so we can quickly determine if we’re getting off track.

Kenton: I hear what you’re saying. Maybe slowing down initially will help us go faster in the long run. I’ll work with my SMEs and customers to identify whom we need to include. I want to make sure we don’t get too many cooks in the kitchen on this one. Can you build a plan for how you want to start? I’ll provide that to the team when I invite them to attend the alignment meetings.

Ryan: Yep!

Kenton: Once we’re aligned on success criteria, we can set up periodic follow-ups with the stakeholders to ensure we stay that way. There will probably be changes as we move forward because we still won’t have certainty on all the details, so I hope you’ll be flexible and willing to change course as we learn things.

Ryan: I can do that. But if we veer off course from the goal, we’ll need a way to get people back on track. Otherwise, we have to make certain that everyone is aligned on a new goal.

Kenton: OK. We are in this together, so let’s have those hard conversations early. You let me know as soon as you smell trouble, and I promise not to point the finger or kick the can down the road with leadership.

The Wrap-Up

How you start a project can often signify how the project will end. In reality, saying “Let’s get started and we will figure it out later” means that the business has not clearly defined success. While we don’t need to do detailed requirements and spend hours in meetings, we do need to have a clear goal that all project stakeholders understand and are aligned on.

Here are some details to establish before starting a new product development effort.

1. Business case: The specific and measurable value you expect the project to create
2. Product charter statement: One or two sentences that clearly state the high-level objective of the product or project. While doing this right may be harder than you think, it’s always worth the effort.
3. Specific list of personas or users
4. Complete list of activities: Capabilities stitched together as “scenarios” or the end-to-end stories you want the system to support
5. Bottom-up estimates: By letting the developers create these for the required screens, reports, engines, and APIs, your estimates will be more accurate. Plus, you’ll have the added benefit of creating a stronger sense of ownership with the development team.
6. High-level release plan: Include regular check-ins that communicate key dates and deliverables for executive consumption.
7. Clarity around people and their responsibilities: Include what they are and are not responsible for.

Regardless of your organization’s approach, if everyone is not aligned on what defines project success, you are headed for trouble. Well-defined success criteria are the guardrails that keep the project on track to meet business expectations.