After reading Scott Berkun‘s excellent book on Making Things Happen. I started to think through how I approach projects and mapped the topics covered the book to my approach(s).
When tackling “things to do” or projects I tend to put on a pragmatic lens of getting things done. However when I think back through all projects that have been successful in my past they all went through basically the same stages. The scope of the stages change with the size of the project, however a little request such as “can you build this query for me” to large projects such as “build the realtime data pipeline”.
Beginning Phases
The beginning of the project is usually brimming with questions. Why are we doing this? What exactly will we be doing? Who’s doing it? There is always a discovery piece in the beginning. To address these questions and bring clarity to the project there needs to be 3 things.
- Vision
- Scope
- Timeline
These things can be large and formal, or small and informal. The point is in successful projects they exist.
Vision
A vision is the “why”. It is deceptively hard to have a good vision. Many times a vision creeps in as the answer to “what” instead of “why”. A good vision will allow you to stand behind the work that will get done as part of the project. Everything that gets built needs to be able to look back to the vision and see it’s role in the project.
Bad visions:
- To be in line with the industry we’re going to build a realtime data pipeline
- Mary wants an answer by Friday
- Pink is the best color, so all images on the website will be a pink hue.
Better visions:
- Faster insights into our operations will allow for intra-day corrections in the business.
- Mary is trying to find out how much money we spend weekly on lunches, next budget deadline is Friday.
- Latest report showed people are mad when navigating our website.
There are always reasons why we are doing a project/task. Once those are known it allows for discovery on what is going to be built. Also inevitability at some point during a project (particularly larger projects) there will be roadblocks and frustrations. A good vision allows people to ask “why are we doing this again?” and get a reasonable answer.
It seems simple, but in my opinion a good vision is critical to a projects success. People feel like there is a meaningful goal and empowered to make their own decision as they line up with the vision. You’ll know you have a good vision when you find yourself and other repeating it..constantly.
A vision doesn’t necessarily have to be written down, but it helps if it is. It could be a document by itself, a section in a document, a email, a tweet, anything that’s searchable and reference-able.
Scope
The scope is more “what” are we going to build. There is usually a set of documents, or artifacts that come out of the scope phase. Scope is where you would write down the requirements, specs, and how we know the project is over.
Again the coming up with scope can be a large formal process that in and of itself takes a while to complete the documents for everything. Or it can be smaller items written down in an email, whiteboard, etc.
Timeline
After you have the general scope you will should get a sense on how long this will take. Are there milestones along the way. Your timeline will be the most externally communicated item in a project.
Note on “Agile”
Maybe if you are on an “agile” team you’ve already given up on this article (“sounds like waterfall, ugh”) and and never got to this point. If you haven’t given up yet though, I want to say this article is compatible with the agile process. Agile is a way to deliver on projects. A well run agile team will have the documents and phased already broken down into smaller chunks so the whole process can get iterated on and get done faster.
Mid Phases
The middle phase is what most people thing of as “work” this is when the concrete tasks of completing whatever you set out to complete is getting down.
- Design
- Building
- Testing
Again depending on the scope of the projects these phases can take varying amounts of time. From weeks to minutes.
Design
Design can start at the beginning phases, however in the mid phase design is really about thinking completely through what is getting built. What trade off will there be. What needs to be done. There may have been specs already, designing here will take those specs and really do a deep dive onto what those specs really mean.
Building
TODO
Testing
TODO
End Phases
There gets to be a transition point toward the end of the project where things are “close” but not “done”. This is the toughest part of every project. If you read any sort of project management literature you’ll see some sort of chart like like
Where in reality I think it’s something more like (forgive my crude free form drawing skills)
There is a hump of effort right at the transition from Mid-End. This is where there usually the most time pressure, there may be a few late nights, tensions are usually the highest as well. The phase at the end are.
- Winddown
- Testing
- Exit
Work is still happening at the start of the end phase, but there should be a mentality shift. From building to shipping.
Winddown
TODO
Testing
Testing shows up again… (TODO)
Exit Criteria
TODO
Why is this project inception?
I didn’t really talk much as to why I called this “project inception”. The thought behind “project inception” is that bigger projects will need to be broken down. All the pieces that are broken down should follow the same basic steps.
- Vision. Scope, Timeline
- Design
- Building
- Vision, Scope, Timeline
- Design
- Building
- Vision, Scope, Timeline
- Design
- Building
- Testing, Wind down
- Exit Criteria
- Testing, Wind down
- Exit Criteria
- Testing, Wind down
- Exit
The outer projects would have formal documents, timelines in terms of months or even quarters, then they get narrowed down to the inner projects where items are documented in emails, or project management software, or GitHub issues (my personal favorite) and the timeline is in hours or days.
Projects are always ebbing and flowing, there is pragmatism throughout these stages. Nothing is ever set in stone, you can always go back, revisit and revise (granted some things will be much hard to change at a certain point). Successful project, large and small, do go through them and are cognizant of the fact that there are stages and which stage the current project(s) is in.
