Project work is serious business that should never be entered into without taking stock of what you know and don’t know. Projects cost money and consume people’s time and energy. If you waste time, money, or energy there is an increasing risk of failure. What I have found in nearly 30 years of experience, looking at projects of all kinds (not just software/systems), is that success starts at the beginning. Put the right pieces in place before you get going.
When you bake a cake you have 4 basic ingredients: Flour, Sugar, Eggs, and Butter. Most cake recipes call for a number of other ingredients, but you will always see some form of the 4 basic building blocks. Having the ingredients is just the prerequisite. Then the baker combines other ingredients, tools, techniques, skills, creativity and passion to make a cake that will satisfy the consumer. The best cakes are a symphony of people, process, tools, and love.
So, what are the 4 basic ingredients for a successful project?
- Prioritized Measurable Outcome Goals
- Prioritized Constraints (Scope-Cost-Time)
- Definition of “Done”
Without these ingredients, you are sure to have confusion and miscommunication on a project. So let’s explore these concepts to gain an understanding of what you should establish or look for on your project.
The vision or purpose of the project is the focal point for everyone. It is the reason that the project exists, defining the WHY. People are driven by a sense of purpose and the vision sets in place the reason why people involved with the project should care about what they are doing. It is a short statement that hits people in the heart. A good vision statement will say what you are doing and why you are doing it. The best ones connect the project to a benefit for other people. I like to ask the sponsors of a project what short message they tell their family and friends when asked. A clear vision statement sets the direction and helps shape the strategy. Without a clear vision, things begin to get foggy for people, slowing down progress and decision-making.
Prioritized Measurable Outcome Goals
Once the vision is set and the WHY is clear, it is important to establish WHAT the project must achieve to be considered a success. These outcome goals should be measurable and prioritized. There are many cases where I have seen organizations perform lengthy up-front Return on Investment (ROI) analysis to determine if they should invest in a project, however they do not measure the outcomes once the product or service is put into operation. That approach leaves out the critical project feedback loop that provides information that could help assess our decision-making process. These goals also help define the features and functions that we need to achieve the goals. Every user story created should relate back to an outcome goal. If it doesn’t then it should raise serious questions about why we would work on the story. Using this approach is an easy way to begin creating the product backlog.
With the WHY and the WHAT firmly established the Product Backlog can begin to be developed. This includes identifying features that work towards accomplishing the prioritized goals which move us towards the vision.
Now comes the fun part! We know for certain that something, and more likely, a lot of things will change as we learn by developing items in the backlog and eliciting feedback from users and stakeholders. One of the major benefits of agile techniques is increasing our ability and speed of dealing with change. That being said, change cannot be unbounded. Every project has some constraint or constraints that are driving it. We are all familiar with the concepts of making trade-offs of Scope, Cost, and Time when making decisions. Unfortunately, I see too many projects in which everyone thinks that those 3 constraints are set in stone by some ridiculous upfront determination when the knowledge level is as it’s very lowest. In these projects you see people sacrificing quality in the hopes of achieving faster speed and/or more scope. But when you look at the system-level process and result of doing that it often proves to take much longer and demand a higher investment. This is why I separate the constraints and the Definition of DONE. I want the Product Owners to make decisions based on Scope-Cost-Time trade-offs and everyone should be accountable for the quality as defined in the Definition of DONE.
Product Owners must steer the project towards a moving target with the goal of delivering the highest value within the constraints. So it is a good idea to determine what the strongest driving constraint is and then make decisions based on that. The fact is that everything is going to cost something, nothing in product development is free. So, an example would be a fixed date project. If we received feedback asking for additional functionality, it would have to be paid for with some combination of Scope and/or Cost (cost being people on a software project). By identifying the priority of the constraints we can increase visibility into the decision-making process. I do this on every project setup when I coach and it always amazes me that the sponsors didn’t really consider doing this in the past.
Definition of “DONE”
I have seen a lot of methods that projects and authors suggest for maintaining a high quality level. Some suggest that quality and completeness type tasks become user stories. I disagree with this in that stories should be focused on user value-added functions, with the exceptional infrastructure story. My approach is to create the quality and best practices standard by establishing a Definition of DONE checklist at the beginning of the project so that there is a clear understanding about what makes the product valuable. I take the organizations development lifecycle, add in the best practices and quality standards and create a single page checklist. This checklist will drive the determination of the skills needed on a Scrum team as well as the tasks that must be completed for each user story to be DONE. This keeps the product backlog focused on user value and avoids the possibility of lowering the priority of quality processes in a backlog for the sake of functionality. A sample Definition of DONE checklist is available on my LinkedIn profile page.
Now its time to bake…
With the four basic project ingredients on the table, we can add other things that we need like user profiles, risk identification, etc. Having the four ingredients doesn’t guarantee success of the project, but it will swing the odds in your favor. The key is to communicate this information early and often. Every user story addition, deletion, reprioritization, or modification should be linked to the vision and goals, paid for with one or more of the constraints, and be turned into something of value following a clear Definition of DONE.
Piece of Cake!