Tools to help you find your way
You’re working on a new project or are managing several. What I believe you and your team need is a simple way to keep track of what you’ve been doing. A way that is agnostic to whichever product development approach you might be taking, but will help you to look back on what you did. A development diary.
To help, I’ve created a template form that you can use to keep track of your project. The basic elements are as follows:
A date period, perhaps monthly, weekly or daily, depending on the pace of your project.
A record of what activity you did to better develop your understanding of the need (your WHY activity). This might be market / user research. User trials, customer insight and validation, Voice of the Customer, customer jobs and outcomes etc… The aim here is to conduct research to better understand the real needs and reasons behind your project objective.
What was the outcome of this activity? Might be nothing, as it could be ongoing, but eventually the outcome of this research should be either supportive or critical of your mission.
Based on this new outcome, what is your level of confidence in knowing whether you are on the right track? Has this outcome increased your understanding of the problem you're trying to solve?
What is your justification for this level of confidence? Since confidence is subjective, what is your reason, logic or justification for this confidence score? How would you defend this score to someone else?
Next we log the development progress, your HOW activities. All project development actions, design development, creativity time, product design, business planning, management, etc… anything that is part of the effort to solve the problem.
Did anything tangible come out of the activity in this period? What was the output? Designs, prototypes, test results, releases etc…
What does this do to project progress? How far along do you think you are? What's still to do, what's the next development priority?
What was the cost of this time period? Include all WHY and HOW activities
(Bonus Optional Extra) Is anything worrying you or of concern? Are there any new risks that have appeared?
When filling it in, it might look something like this:
Drawing Conclusions.
From the entries in your project diary you should be able to construct a project map to represent visually what’s been going on. But some hints can be found straight from the diary.
Driving Blind
All the activity is in the HOW side of the diary. Which might be fine for a routine project, but for anything involving designing for people this is a problem. A diary like this represents a likely insufficient understanding of the customer, the need or how the solution being developed will affect the customer and the desired outcome. High chance of project failure, under-performance or rework.
Driving from Memory
You asked some good questions and have confidence in your direction, but that was some time ago now, things might have changed, you might have drifted from the original intent by mistake… time to check.
Inefficient Development
Lots of rapid new prototypes or feature releases with little understanding of the need until the end. Commonly known as the “Build Trap” in software development. In short, why did you bother making all those new versions if you don’t test them at the time? The more tweaks and changes you make, the more features you add the more complicated it becomes to understand the customer feedback.
Ineffective Research
The flip side to doing to much design and development… not doing enough.
Lots of customer research and discussion performed, but very little knowledge or understanding uncovered. Very few meaningful outcomes.
Too much of a “butterfly”…
Time Management Issues
My biggest challenge, and a very common problem when trying to juggle many projects at once. There never seems to be enough time to really focus and get things done. As a result it often takes longer and the outcomes drift away from the goal.
Keeping a record of what you’ve been doing and why can help you get back up to speed quickly and pick up from where you left off.
Can I just keep it all in my head?
Of course you can, and for simple or short projects I tend to, but I’ve been thinking in this way of dividing everything I do into a WHY or a HOW activity for sometime now. So have developed a natural alarm clock that goes off if I’m spending too much time on one side or the other.
For long or complex projects I strongly recommend keeping a written record. It’s the only way to objectively know at the end of the project, when the score is up on the board so to speak, what could have been done differently. Relying on your memory, as any lawyer in court would tell you, is not a good method for hard evidence.
Managing Projects from your diaries
Using the cost and confidence scores to help you review progress
Controlling Risk
A key element of project management is controlling the known and unknown risks of any activity to ensure there are as few surprise shocks as possible. This is a fundamental part of the Stage-Gate Method and why it has become the gold standard of industry practise.
It is however not without it’s flaws though. One of the biggest being it tends to focus on the technical delivery rather than the understanding of the need and has little monitoring scope within a Stage. So to support the Stage Gate approach, I believe your project diary, and the corresponding jump & dive project map, can be used to review whether a project appears to be on track or not, between the various Gates.
Example
In this example comparison shown here, three projects start at the same time and all have exactly the same spend profiles throughout the duration of the project. The vertical axis is an equation of Cumulative Project Cost divided by Cumulative Project Confidence:
Project One - follows a traditional project process model and attempts to uncover deep understandings of the need right at the start. Then all the focus is on solving that problem. Whilst I think this is near impossible for novel problems it should be possible for routine ones.
Big WHY at the start then all HOW
Project Two - performs regular small customer validation steps continuously throughout the project, as the solution develops it is regularly tested with users.
Lots of WHY activities regularly spaced alongside the HOW
Project Three - does no validation of the customer need beyond what they were given in the brief until they have completed the development activities.
Classic builder, all HOW and no WHY until it’s ready at the end
For all three projects, the same rate of confidence decay has been applied, so that all confidence fades over time.
As the three projects progress, the lines of the projects with no further WHY activities during the development phase (1 & 3) start to climb ever more rapidly. As costs mount but there is no new confidence level to bring it down. At some point projects 1 & 3 will cross a nominal threshold that is your acceptable level of risk. (How much time and money are you happy to spend on something without knowing that someone will want this solution?)
So it’s a useful way of reviewing your projects to see which are safer bets than others. Any project operating above this line needs to conduct some confidence building activities to bring it back into the safe space.
Project One, whilst a safe bet at the start, depending on the length of the project will at some point no longer be such a safe bet. Whilst Project Two stays a safe bet throughout.