Lessons Learned in the Quest for a Perfect Project Discovery Process
This blog post is the second of an in-depth, two-part series on Rangle's project design discovery process. If you missed part one, you can find it here: Project Discovery in a Lean Agile World: Introducing the Clarity Canvas
This is a brief overview of some of the main problems we ran into while developing the Clarity Canvas process. It’s not exhaustive by any means but it will give you an idea of some things to look for, and hopefully overcome, in your own attempts at customizing this process to your projects and organization.
Level of agreement across client stakeholders:
One major problem we saw happening time and again, on projects that had gone poorly, was a lack of alignment followed by a breakdown in communication. On further inspection, we discovered that things always lead us back to the project kickoff.
“What is the goal of this project?” It was clear stakeholders rarely had the same answer to this question and many have never talked about it in any depth. It’s deceptively difficult to get agreement on clear priorities for a project. The technical lead might value certain architectural characteristics and non-functional requirements like accessibility, performance, analytics and internationalization whereas the product lead may value rich features, custom fonts, animations etc. In many cases, the outcomes can be hard to measure since it's rare that the stakeholders have made the connections between the product goals and the desired business outcomes.
Translating a goal of good user experience for an application made for employees should improve efficiencies that can be measured by time saved and as an extension money saved. The same can be said for making an application intuitive; it should reduce the number of support requests and increase retention resulting in favourable business objectives.
On the other hand, we may also need to train and answer questions for the client's development team to be able to support the application after the engagement.
Although we have created tools and processes to speed through these common situations, investing in these cross-cutting concerns impacts the velocity of the project and can push deadlines out of reach.
By exposing all these expectations, the need to focus becomes apparent. It needs to be made transparent so the client has more control over how they make use of the available resources. Clarifying the outcomes the project will enable provides context to evaluate priorities and better focus effort. Stakeholders go into problem solving mode, negotiating among themselves over what should be in scope for the given time to increase the likelihood of success. For instance, if the immediate priority of the project is to demo in a sales presentation, it will not need to be infinitely scalable or handle fringe cases in the first pass, perhaps the initial focus would be on delivering a workflow to empower a sales presentation. Knowing that would allow us to focus our effort on the things that will have the most impact as agreed on by all stakeholders.
Similarly, if a key stakeholder isn’t able to attend it’s important to flag that as a risk to determine whether their input might change the direction of the project.
Level of preparation:
Another challenge we’ve learned to adapt to has been the level of preparation the clients have coming into the consulting engagement. Some clients come in with a concept and some strong ideas about what they want to do and others come in with an existing application and/or large specification documents.
“One of the most challenging concepts we negotiate is the difference between delivering value v.s. delivering features.”
Preparation can be a double edge sword, on one hand, preparation helps make communication easier because research has been done and there are fewer potential unknowns. On the other hand, preparation often correlates with inflexibility. One of the most challenging concepts we negotiate is the difference between delivering value v.s. delivering features.
In cases where there is a specification, it’s very likely that the features and arrangement have not been measured to fit the time and resourcing for the project. It’s also likely that it hasn’t taken into account available libraries that can be leveraged or the state of the technology at the moment when it’s being built, versus planned, or the unique talent of the team. These lead to challenges that slow down development and push deadlines out of reach.
Focusing on features often also makes it challenging to see overall priorities. Development teams focusing on features tend to start the project building very rich features until they realize they don’t have time to complete the remainder of the project at that level, forcing difficult decisions and often causing abandoned or failed projects. Focusing on value (solved problems through complete flows), within a time budget, allows the team to develop solutions based on the information available at the time and the client the agility to plan based on the latest information.
Level of confidence in current understanding:
Measuring the level of confidence in the information provided helps the team create a list of action items to get more confidence in information that if incorrect, could derail the success of the project.
Some of the issues that can arise here include:
- Majoring in minor things (focusing on the wrong project goal)
- Inaccurate target users and incorrect project focus.
- Designing for an incorrect or outdated end user process
- relying on API’s that aren’t complete or reliable
- relying on technical solutions that aren’t available or reliable
Generating these assumptions and research topics, provides context to design our research and validation activities. We use a variety of research techniques depending on the subject we want to learn about:
For risks related to the direction of the project, we work with the client’s product owner to reach out to the relevant stakeholders to get their perspective and work with them to integrate it into the current plan.
For technical risks, we evaluate existing solutions and create a research spike to evaluate how something can be done before the related feature becomes the highest priority and included into a sprint.
For risks related to the accuracy of target users and their needs, we integrate a combination of user research techniques, usability testing and analytics into the development process.
For risks related to product market fit, we integrate lean startup style MVP and marketing experiments measured through interviews and analytics.
For timeline risks, we employ relentless prioritization and time budgeting at the problem level, allowing for the creation of appropriate solutions within that time budget at an appropriate technical and feature fidelity.
We’ve developed downstream frameworks to quickly understand and execute on these research activities.
The beauty of constraints.
Rangle has evolved a culture intent on pushing the product development process towards its ideals. This reflects itself in clear value based company wide decisions.
The following principles and practices guide our Rangle Flow Process:
- We practice SCRUM.
- We adopt lean practices as much as is possible (real results over simulations).
- We keep code and product quality high.
- We empower self organizing teams to do their best work.
Our integrity across these clear values has allowed us to develop confidence and predictability in our approaches, resulting in well worn paths and accelerated development of our tools and processes.
Within these constraints we’ve been able to develop a rigorous process for discovery that’s condensed into one or two focused meetings (Project Discovery in a Lean Agile World: Introducing the Clarity Canvas), making it easier for everyone involved to attend.
Always learning and improving.
We have already executed the Clarity Canvas on many projects and we keep learning. We are constantly improving the effectiveness of the session as we learn from unpleasant surprises during projects, when we prepare new hires to facilitate the session, and as we observe the characteristics of the participants during the session.
We’ve learned from other documented processes and discovered and fixed the pitfalls inherent in them. The processes described in Google’s Design Sprint, Lean UX and others seem to have context limitations and do not work well for a consulting practice out of the box.
These lessons have contributed to a repeatable and scalable process for project discovery designed to effectively reveal and share the context necessary to confidently get started developing. With focus, alignment, and shared context, on agreed upon and immediate priorities, our process ensures projects ship quickly and successfully time and again.
Still have questions about how our design process can be applied to your e-commerce web or mobile project? Contact us to learn more about strategies that have worked for retail clients including Aldo, Uniqlo and Priceline.