Know the “Why” behind Your Projects
You’re working on a project or a series of tasks for some deliverable. Do you know why? The reason behind the project explains the value of your work.
You might work on something just for the fun of it. Back before I had children, I bicycled, crocheted, and needlepointed. I made time for these hobbies because I had fun doing them. Once I had children, my personal hobby time decreased, so I made other choices for fun. The fun was my “why.”
Every project has its own unique reason for existence. We might have fun doing this work, but the organization is not so interested in our fun. Most of the time, the purpose of a project is to solve a problem.
Uber and Lyft decided to attack the problem that you could never find a taxi when you needed one and you often couldn’t use a credit card. Towns and cities limited the number of taxi medallions, which inflated the prices. And some taxis were smelly and not clean. With the new competition, cars are more abundant, are cleaner, and predict a fee range so I know what price to expect.
That motivation—create an easy-to-use way for people to use a taxi-like service—is the “why” behind Uber and Lyft, and it is also the mission for those organizations.
Do you know the “why” for your project or program? I often see missions described like this: “Clean up the mess from the last project.” Not very compelling, is it?
Instead, I like to understand why we want to do the cleanup. Will it benefit our customers in some way? Will it benefit us to remove waste?
Here’s the problem statement for my book in progress: People often equate agile with Scrum. Scrum is for a collocated cross-functional team, and there are many more options than just this best-known agile approach. My job is to explain the options and when you might want to select each one. When I use a problem statement like that, the “why” is clear.
I can add release criteria: Finish the first draft of the book by May 1, 2017, so I can get reviews. I have a final deadline in mind. I won’t know if I can meet that final deadline until I receive comments about the first draft.
My problem statement is also the project vision. Coupled with release criteria, I know what’s in scope and what’s out of scope and why for my project.
Sometimes, we work on something because it’s fun. We more often work on projects to deliver some kind of return for our organizations. When we know the reasons behind our work, we can be more successful. Knowing why can create success.
