You've Signed the SOW, Now What?
The signatures on the contract are fresh and now it’s time for the real work to begin. But before your team starts moving cards in Jira or ADO, there’s some groundwork to do to ensure the project is set up for success.
The iterative software product development process today follows a fairly common playbook regardless or whatever flavor of Agile, Scrum, etc. you prescribe to. But sometimes, a software product is destined for failure if several steps haven’t been taken before you get into the nitty gritty of development.
In this series, we’re going to share our process for ensuring the product is successful by getting the project off to the perfect start. In the first part, we’re going to explore optimizing the team to ensure success.
Separate Stakeholders from Actual Users
A typical software project team consists of “project people.” This likely includes a product manager or product owner, a scrummaster, a designer, some number of developers and QAs, maybe even some DevOps folks.
But you’re not building the software for the project team working on it. And you’re probably not building the software for business stakeholders or other people you are talking to when you get ready to kickoff the project. There’s some other folks out there who are the ones who are actually going to use the software: workers out in the field, someone in a distant or remote office, or normal everyday people like you and me sitting behind their computer screens ordering stuff from an ecommerce site.
It is imperative to have the actual user’s voice represented throughout the entire process. This means you want to orient your project kickoff and the information gathering phase around those folks mentioned above — the people that will actually be using the software product.
These end users know their goals, the features they want and how they will use the software. And it’s probably not the way that you or other stakeholders who are a step removed would think about going about it.
You’ve gotta get to know these folks. They should be the focus of your kickoff. It’s ideal to have them in the audience, someone who is actually in that role or someone who knows that end user very well and can represent their views and interests.
But beware end user representation by proxy. And if you have no other choice (which is common), then you need to make it clear that that proxy needs to really know the end user, have access to them, be able to evaluate and communicate that user’s needs accurately and concisely. Avoid proxy representation of your end user if it’s just someone being assigned that role and responsibility arbitrarily. The project you’re about to kick off and all the things you are about to define as must-have features etc. will be based on an understanding of that user or users’ needs.
So don’t kick your project off and start building based on assumptions. Or the features you design and the backlog you create won’t be for a real person; it’ll be for some pseudo-user you made up based on a bunch of assumptions about what you thought your end users wanted. Question those assumptions. Escalate them to your key stakeholders and leadership. Make them known for what they are — assumptions, poor or hasty decision making, a lack of clarity or consensus on the project objective and the real audience that will use the software.
Make getting to know your user your mission, make their voice present and loud and clear when you kick off your project; you’ll set yourself up to have a much better time and more success. Otherwise, if you are timid or otherwise reluctant to have that conversation with your client or stakeholders, don’t be surprised when you’re looking back a few months down the road and the features you built have low-to-no adoption and your stakeholders are asking you why?
Resign yourself to ask the hard questions now. Believe me, they’re a lot easier to answer now than trying to answer them after the fact and after spending a lot of money developing features that go nowhere.
Making the actual user of the software product the focus of your project kickoff will help you ensure the project team understands not only who you are building the product for but also what they value in the product. This empowers your designers, your developers, and your other project team members to come up with creative solutions to actual end user problems. You will inspire your team to build features that provide actual, real-world value. And that is fulfilling, meaningful work that will produce meaningful results. And a happy project team!
Once you bring the proper team together, it’s time to kick the project off. We’ll cover that step in the next installment.
Josh Luedicke
VP of Product
Josh is VP of Product, bringing more than a decade of product innovation, human-centered design and iterative software development experience across multiple industries to Umbrage’s clients.
Check out our case study with Cold Bore.
