So, you’ve got yourself a start-up on your hands? Or is it a new project that’s coming in, and you don’t know where to start? Don’t worry, we’ve got your back!
Oh and just so you know, we won’t be gnawing at your ear with best practices - we’re sharing real-life experience here!
First things first, let’s look at the problem, because all good things start with knowing what you’re trying to solve.
A new project is coming in and your client needs a partner, not just someone to execute development. This can be challenging because several things need to be put in place to make this partnership as smooth and as clear as possible.
STEP ONE: Audit your Client’s setup and expectations
This step is crucial for you to align yourself with the Client’s expectations, but also for you to know what their capacity is to support you in any proposal you might come up with. Some Clients have great ideas, but not a lot of manpower to execute those ideas - which is why they come to you in the first place - but this also means that you need to know how involved they wish to be in the partnership and who carries the weight of the process.
Your options here are:
- RACI matrix - we all know this one: responsible, accountable, consulted and informed - hit the ground running with a concise overview of everyone involved. This can be a simple table with Roles in the project, or it can be an in-depth analysis of existing Roles within both organizations, who will be newly assigned to work together within this RACI matrix.
- Design thinking workshop - something that’s been buzzing in the community is design thinking - and to not abuse this broad term, we’ll look at it from the perspective of “making sense” of your new project. A design thinking workshop is a great way to brainstorm ideas and expectations of the upcoming work and come up with first initiatives that need to be put in place to set up a working process for your project.
Definitely one of the most important things is knowing what you’re working with in terms of manpower.
How many roles can the Client commit to the project? Will those people be involved from start to finish, or will some of them “fall off” as time goes by? What are their roles?
Write these down and place them within the process to have a good overview if all roles are covered. And don’t worry, we’re not telling you to do extensive research into this, or to do hours long workshops to make this work. If your Client has a busy schedule and cannot set aside a time to sit in a meeting, it can be a Google Form questionnaire with pointed questions sent out to all people involved, and you can set up the matrix depending on the results of that questionnaire.
STEP TWO: Tear into that Brief like it’s going out of style
If you’re anything like us, you love a good Brief. A one-pager that describes what needs to get done with some overall hard-hitting questions like:
- What needs to be built?
- What is the budget?
- Are there hard deadlines?
- What’s the worst possible outcome?
- What’s the best possible outcome?
Of course you can expand this to give you more info about brand alignment, market research, etc. but that can be a SWOT (Strengths, Weaknesses, Opportunities, Threats) analysis for later.
The basis of the project should always be as simple as possible to minimize room for errors or misunderstandings along the way. Ideally, you should have a Brief template prepared for your Clients, so you get the most out of the information you want to get.
If a Brief comes directly from the Client and is focused more on the work itself, that’s a good start for a “work focused” workshop with your team, but we strongly suggest you cover your bases at the start of your work relationship and not somewhere in the middle, where you’ve “burned” half your budget on writing specs.
STEP THREE: Break it down!
You can do a little dance, too, but we mean breaking down work that needs to get done.
Different people have different approaches to breaking down necessary work, so we’ll offer up a couple of solutions on how you can manage your Client’s expectations, and stay within budget.
MOSCOW - Must Haves, Should Haves, Could Haves, Won’t haves.
Believe us, you wanna start with everything in the Won’t Have column and start from there.
(Especially if you’re looking to scrape out an MVP to test your Concept, rather than do a full work breakdown without having information on feasibility)
Why start with having everything in the Won’t have column first?
Let’s use an example here: Your client wants to build a mobile game. The mobile game is a simple shooter game where the user can shoot balloons on their screen.
So you’ve got a bunch of ideas in the MOSCOW board, for example: 3 different types of balloons, power-ups the user earns by shooting balloons in quick succession, GUI with dark and light skin possibility, etc.
Ask your Client: Can the game exist without 3 different types of balloons? Yes, it can. It can be only one type of balloon, so we move 3 different types of balloons to the Could Have Column, and place 1 Balloon Type to Must Have column.
Can the game be competitive without a GUI with scores? No, it can’t, it has to go to the Must Have column.
Use that approach to go through the list of features that make the Product.
What happens with a well prepared MOSCOW board, is that once you get your estimates in, and see that “Could haves” are eating away at the budget, you can offer your Client possibilities, with the option to have the “Could haves” developed later.
This approach applies not only to “Products”, but also Processes within an Organization.
Can a department work efficiently without having a work management tool? No? Then it’s a must have and you build around the budget you have to look into a tool that can accomplish this goal.
2. Work Breakdown Structure (WBS)
For more complex work, especially involving multiple parties and/or multiple systems that have a lot of dependencies, a Work Breakdown Structure might be the way to go.
A Work Breakdown Structure lists and defines the breakdown of work from a perspective of Delivery - What needs to get done, Who needs to do it, What are the dependencies, Who is involved and Defines prerequisites and Deliverables. This makes it more stringent in the way work is approached, with less flexibility, since it “dives deep” into the work that goes in and the actual outputs of that work.
3. Story Mapping
Another approach is building work structures using Stories (yes, SCRUM sneaks in everywhere!).
Stories are a good way to map out what needs to get done because it takes into account users of the finished product and what they should be able to do, and for what purpose. The “how it’s going to get built” is usually something developers come up with later on, but if you’re mapping out processes, you can of course touch on how you might want something to work, because you are defining work to accomplish a goal for a certain role.
For a good Story Mapping session, our recommendation, as always, is to come prepared.
Do a User Role Matrix (URM), write out all the roles in the project or process and a simple Y/N approach to whether a certain role is able to do/access a certain thing.
Story Mapping can be either really simple or really complex, depending on what you’re working with, but preparation for this type of session is key to both sides coming out of that meeting being able to pinpoint what to expect in the next steps of the project.
One thing we can’t forget is Risk Assessment. Once you’ve got your work breakdown, ask all parties involved what they see as potential risks to getting where you want to go.
Are we using new technology?
Are we unfamiliar with a new tool we want to implement?
Are we using a third party library that could one day be deprecated and cause many headaches? Got them down?
Great - now assess those risks as Low, Medium, High/Critical and come up with a contingency plan in the event that something goes wrong.
STEP FOUR: Get estimates, build timelines!
Now that we know what we’re building, we need to know how much manpower needs to go into it, and when those can be delivered.
Since you’ve already done such a good job breaking down the work in Step 3, getting estimates for the necessary work should be a breeze.
Always good to mention - Estimates are not Timelines and should never be treated as such.
Your timeline should always include every single participant, their vacation time, potential sick leave (especially for projects longer than 6 months, and in the “winter months”), national holidays, bugfix times, etc. In your timeline, never put your delivery milestones immediately once development is finished. Always think about leaving time for QA, bug fixing from that QA and leave time for your client to review everything before they sign off on it, because your Client’s review could come with potential revisions and fixes.
Same with processes - they need to be validated so set aside time for people involved to have the time and space to test everything.
We'll stop here, not to overwhelm with possibilities, but as you can see, setting up your project requires you to know which tool or method to use in a certain situation.
Here's a brief "tl;dr" video for you:
If any of this feels daunting to you, worry not, we can help!
The team at Product Pixie eats processes for breakfast, so contact us if you have anything you’d like to discuss with us, or if you like what you see and you’d like to apply the above practices on your own product.
You can follow us Instagram as well, where we'll bring you nuggets of wisdom and experience and sometimes a good laugh at our own expense.