Get certified - Transform your world of work today


Project Success?... Piece of Cake!

4 February 2011

Bob Schatz
Agile Infusion, LLC

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?

  • Vision/Purpose
  • 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.

Prioritized Constraints
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!

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 0 (0 ratings)


Bob Schatz, CST,CSP,CSM,CSPO,REP, 3/24/2011 8:04:33 PM
Conflict in Libya...

Notice how the controversy over our involvement in Libya (a project) is causing conflict within our government. Listen to the themes:

No Vision: Don't know WHY we're there
No Goals: Don't know WHAT we're trying to achieve
Constraints: Don't have any identified Scope, Cost, Time constraints
No Definition of DONE: No idea what the completion criteria are

Doesn't matter how you execute because there's nothing to measure progress against.
Biondi Tang, CSM, 3/31/2011 8:23:17 PM
The larger the scale of the project, the more difficult to have the four ingredients right.
Bob Schatz, CST,CSP,CSM,CSPO,REP, 4/1/2011 9:48:31 AM
This is correct. And that is why you don't invest huge sums of money in something until you have a common understanding of what we are trying to achieve and why.
Andreea TOMOIAGA, CSM, 7/21/2011 3:08:45 AM
Hi Bob, I found this article very useful and in my opinion clearly comprises the relevant components of progress measurement and decision making enablers. Constraints are an important part of it. If we think about Theory of Constraints and about Management by Objective we need always to have in mind the biggest constraint at one time and have a plan of action to overcome that driving constraint. This process of keeping track of constraints should be in my opinion, iterative in order to ensure that the next big constraint is identified, monitored and some corrective action is performed on it. Identification and assessment of constraints and their clear prioritization are an enabler for decision making and overcoming constraints enables progress measurement.
Bob Schatz, CST,CSP,CSM,CSPO,REP, 7/21/2011 6:45:48 AM
Hi Andreea,
Thank you for the comment. I think there is a distinction between the constraints for the project, and constraints in the process (which you are speaking about). Project constraints are related to the driving factors for making trade-offs. For example, if we have a project with a fixed time (ie, has to be operational by November 1) then we have to steer the project without extending time. Hence, decisions and trade-offs must be made based on scope and time.

I completely agree that we do need to constantly monitor and look for constraints in the process and use Theory of Constraints for smoothing the flow of value in a system. As for the MBO, I feel is a horrible practice in business because it drives silo behavior that does not serve the end-user well.
Andreea TOMOIAGA, CSM, 7/21/2011 8:42:00 AM
Hi Bob, thank you for your comment. You are right, I had process constraints in mind. Regarding MBO, if one would regard objectives as modalities to deal with constraints encountered at project level and these are to be considered ordered by their priority as far as the business value is concerned, then I think this practice helps in the decision making process and helps deliver business value faster for a certain project. This implies of course that team members are conscious of the business value and move toward the objective of delivering it.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up