So we have the Cycle of the Tide. Question now is how to actually execute that cycle. What are the conditions of success? How should we break up the projects into bite sized pieces? How should we work out prioritizations? What kinds of tracking should we put in place? Who are our stakeholders? How do we attract new talent? Yea, you get the idea - there's a lot of distance still left between our abstract set of goals and clear execution itself.
To help us start covering this distance let us first recognize that there are essentially three components to the Tide Cycle - finding projects, executing on projects, and incorporating talent. In my mind the middle of those three is the axel around which the other two pivot, so in this post I'm going to do my best to lay the groundwork for execution.
Lifecycles
Figuring out all the bits and bobs one has to pay attention to to manage a project is no small task. Thankfully there's a trick I've found very useful in the past - thinking about projects in terms of lifecycles. By being able to break a project into a lifecycle, we can focus on understanding each of the lifecycle components and how they relate to one another rather than trying to understand the whole all at once. Then once we've understood the details of each component we just add 'em up together to get the whole. So then, what is the lifecycle of a project?
Design
All projects start in the same place - as an idea. At this stage there's a lot of unknowns. You don't necessarily have a perfect grasp of the problem or its context. You may not necessarily know exactly how what you're going to build is going to be used. You won't yet know all the tools you'll take advantage of or whether you've got the right resources in terms of data, compute and money. So it's important to dedicate a significant amount of time and energy to thinking and designing what's actually going to get built. That being said, it's easy to get lost in all the questions, so let's break it down.
What Are The Problems?
This is the most critical question of all. Too often projects are built around solutions that someone dreamed up to a problem that same person barely understood. Given there are no lack of great articles on problem vs solution based thinking I won't go into detail here, but suffice it to say that you must ensure that you've framed your project in terms of a set of problems and not in terms of a set of solutions.
What's The Ecosystem?
Answering this question is foundational to ensuring that what you build will actually get used. You have to understand the ecosystem your product is going to become a part of and how your product is going to get used. If you build an awesome GIS tool but then realize that it doesn't integrate with any of the tools the organization you're helping uses you're going to be really disappointed. Absolutely ensure that you understand how what you are going to be building is going to be used.
How Will This Be Extended?
Remember the purpose here is to catalyze action and building toolsets - not build finely tuned solutions. To truly catalyze action we must "teach a person to fish". If you build a model for someone that has to be retuned every time the data is updated, then you'd better make sure your users are able to do that tuning otherwise you won't have catalyzed anything. Therefore you have to spend time understanding how they will extend and update the tool so that you can build in the features required to make that doable for them. Self sufficiency has to be a goal here.
How To Make This Reusable
An equally important goal is to ensure we're building toolsets that are reusable across a range of problems and not just solutions to a particular problem. Only by creating this kind of reusability can we ensure that we're accelerating our overall development across projects. This is an essential part of the Cycle of the Tide and therefore must be a priority in our brainstorming and design.
Has This Been Done Before?
A step often missed in the excitement of starting a new project is simply finding out if there are examples already out there to learn from. Take time to look at the body of work that already exists because anytime you can learn from someone else, the better.
What Are The Possible Architectures?
A solid architecture is essential. It's the tool you use to create a framework for good engineering practice. This is where you get to think about how best to modularize the work, how to take advantage of prebuilt tools, how to build good interfaces, how to test things well, etc. It's also where you'll start thinking about the problem end to end. Creating thorough possible architectures will save you a lot of time and pain in the long run.
What Will We Use To Build It?
Compute, data, tools, models - this is where we think about and enumerate our options for actually putting meat onto our architectural bones. No need to explain why this is important.
Now I expect you may be wondering - if we've just started this project, how on earth will we possibly have all the information required to answer these questions? For example what if we've just been asked to build a model and have yet to even understand what data sources we have available? Answer is, you don't have to be able to answer them all. The point of the design exercise is as much to discover the known unknowns as much as it is about actually answering questions. Indeed the result of your design work should never be a list of answers. Rather it should be a list of hypotheses and known unknowns. The hypotheses are questions you think you have the answer to while known unknowns are the ones for which you don't. This then is the real purpose of the design stage - to elucidate your assumptions and questions in a clear and well organized manner. Actually answering those questions and testing your assumptions is dealt with in the next stage of the lifecycle. But before we jump into that there's one last piece to the design stage we haven't addressed yet.
How Will We Fail Fast?
You'll notice that so far we've been working to discover our known assumptions and known unknowns. This should leave anyone who's managed a project before with a nervous question - what about the unknown assumptions and unknown unknowns? These are often the project killers.
For example you'll have designed everything out beautifully, been building gorgeous modules and api's for months, only to discover that a tool you've used for ages has some edge case lack of support that you absolutely need thereby bringing your whole enterprise momentarily crashing down. Not a great feeling.
Unknown assumptions and unknown unknowns are the mismatches and gaps between our mental theories of the world and the way the world actually works. Therefore the only way to find unknown unknowns is by integrating things into the real world. This means getting your tools used pronto. The faster you can get something into someone's hands (even if it's missing features or is just a mockup) the better because that means you're rooting out the unknown unknowns sooner rather than later.
Therefore it's of the utmost importance that part of your design is a plan for getting products into people's hands as quickly as possible regardless of whether those products are complete, partial, or just mockups. I call each of these incremental products Minimal Lovable Products or MLPs. So beyond our enumeration of hypotheses and known unknowns, an MLP plan must also be a product of our design process.
With that last piece handled we can now move onto the next stage of a project's lifecycle - hypothesis testing and experimentation.
Hypothesis Testing And Experimentation
The actual descriptions of this stage and the next are actually quite short. That's because thanks to your thorough designing process, the whole program for the rest of your project is already set down! Now all that's required is going through and ticking off boxes.
So what actually goes on during this stage of the project? Remember our main goal is to fail fast and iterate quickly so that we can uncover unknown unknowns effectively. Therefore this stage is all about getting to the point where we can build something to quickly get in people's hands - i.e. our next MLP. That being said we may also have some rather existential questions looming about that fall into the known unknowns category. We obviously want to deal with those as well. As such this stage can be broken into two parts:
Addressing the known unknowns and assumptions that threaten the feasibility of the project.
Addressing the known unknowns and assumptions needed to build our next MLP.
Finally, this stage is not just about answering questions but also considering the ramifications the answers have on our design. As we tick off the questions and validate our assumptions we must also update and and expand the design to match. Therefore with each question we answer we must ask ourselves how they impact each of the sections of our design listed above.
Development
We've finally made it to the point where we have enough information to build some kind of minimally lovable thing! The purposes of this stage are simple:
Build our minimally lovable product (remember it might be as simple as a mockup).
Get our MLP into the hands of some users.
Document what we created and how it was received.
Update the design with what we've found. (Use the questions from the design stage to guide the investigation)
This will be where those unknown unknowns show their faces, so it's important that you stay on the lookout for them by asking whether anything about your original answers to the design questions have changed in light of what you've actually found to be the case.
Also worth mentioning here again is that catalysis comes from self sufficiency so on thing to keep an eye out are cases where a tool requires extra features to allow for that self sufficiency. These should not be ignored.
Again!
At this point you've answered a lot of questions, validated assumptions, created an MLP, discovered some unknown unknowns, and just generally done a lot of work. Now what? Well now it's time to repeat. You'll have an updated design and a next generation MLP to pursue, so it's back to the hypothesis testing and experimentation needed in order to pave the way toward your next MLP.
Eventually, as you keep repeating this cycle, you'll end up with all your questions answered and a final product that's already comfortably in the hands of your users. And so the development cycle will be complete.
Keeping Track Of It All
Alright that was a lot so let's summarize:
Design: Using the questions listed above as a guide, create a compendium of assumptions and questions as well as a plan for MLPs.
Hypothesis Testing and Experimentation: Answer any existential project questions and broach the hypotheses and questions needed to tackle the next MLP.
Development: Build the next MLP, put it to use, and observe the results.
Repeat: Onto the next MLP.
With this lovely lifecycle in place I hope it's now clear how to track the development of a project. Each stage has clear goals that should be concrete enough to allow for setting expectations while the overall project can be tracked through the repeated cycle through each of the stages with updates to the overall design. To help illustrate this I've thrown together the following super basic templates.
As you can see, the overall project state can be captured in one place while the history of the project is tracked by the various "sprint" cards built up over time. Altogether these capture everything from the roadmap, to the day to day tasks, to the project's record at meeting expectations while also capturing the results, learnings, and features found and built along the way.
The Development Cycle
So there you have it - my take on the development cycle and how to keep track of it. Obviously there are plenty of other ways to manage projects out there, but I hope, at the very least, this perspective provides you with some useful food for thought.
Comments