Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Project Management

No News is Bad News - Feedback Must Create Steering Signal from Plan †

Herding Cats - Glen Alleman - Wed, 08/20/2014 - 22:41

Screen Shot 2014-08-20 at 12.39.03 PMProject Manager: How's the project progressing to plan? 

Developers: We're spending money, consuming resources, producing outputs that the customer likes. 

Project Manager: I was more interested in what's our performance against our planned spend, planned resource consumption, and planned outputs of value to the customer? 

Developers: What do you mean, we didn't estimate any of that, we're managing this project with #NoEstimates. You know that new alternative to estimates for making decisions in software development. That is ways to make decisions with "No Estimates." of the impacts on the future of those estimates or of our work on the future cost, schedule, or technical performance. You know where we can use Decision making frameworks for projects that do not require estimates, or apply Investment models for software projects that do not require estimates, and have our project management methods for risk management, scope management, progress reporting, not require any of those annoying estimates. 'Cause we kinda suck at them anyway, so we just decided instead of learning how to estimate, we'll just not estimate and get back to coding.

Project Manager: Oh, you mean that approach of managing other peoples money that violates the principles of software microeconomics with Open Loop Control - where our organization can make business decisions on the allocation of our limited resources, without examining how those decisions effect the supply and demand of our resources. You do know about those resources? Like money, people, and time?

Developers: Yea, we don't need any that mumbo jumbo microeconomics that we all learned in school, since we didn't pay attention in that boring the statistics and probability class that tried to teach us that all variables on a project are actually random variables and we should to know something about their behaviour in the future if we're going have a hope in hell of ever managing this project in the presence of uncertainty about those values.

Project Manager: What's that smell? Maybe we'd better start rearranging the deck chairs on our ship here real soon, cause I smell an Iceberg getting closer.

No project can be managed to successful closure in the absence of steering targets defined at periodic intervals for the expenditure of cost, schedule, and technical performance. Knowing what those steering targets should be requires estimating their values, then measures the actual values to develop the needed steering signal - the variance between plan and actual.

The only way out of the need to estimate those intermediate steering targets is to straight line the budget, schedule, and needed technical performance - from start to end, then measure the actual performance. 

Like the intended route of the Titanic, our project does not proceed in a straight line, so that idea is a non-starter. And like the Titanic, our project cannot confuse the intended speed with the actual speed, just like we can't confuse the budget - the total planned crossing time - with the actual cost - the actual total crossing time.

Titanic-Route

Without those pesky intermediate targets to steer toward - those targets created by estimating the needed cost, needed scheduled arrival date, and, needed capabilities on the needed date for the needed cost. We're managing the project Open Loop, driving in a straight line. Never knowing what will pop up in front of our path. 

Say good bye to Kate Leonardo, you're gonna get wet.

† Full attribution for the inspiration for this post comes from the very useful blog by Gene Hughson

Related articles Staying on Plan Means Closed Loop Control How Not To Make Decisions Using Bad Estimates Control Systems - Their Misuse and Abuse More Than Target Needed To Steer Toward Project Success Why Project Management is a Control System
Categories: Project Management

The Agile Household: How Scrum Made Us a Better Family

Mike Cohn's Blog - Wed, 08/20/2014 - 20:13

I’m always fascinated by stories about Scrum (or any agile process) being used outside of software development. When Martin Lapointe told me how he and his family used Scrum -- and especially a task board -- to manage their recent relocation from Paris to Montreal, I immediately asked him to share that story. I’m sure you’ll find it as interesting, amusing, and informative as I did. - Mike Cohn

Ever since discovering the “Agile Manifesto,” I have been trying to integrate its core set of values into my day-to-day routines in hopes of improving processes outside of the office environment. With this in mind, my family and I embarked on an agile adventure that produced amazing results we never expected!

Since my childhood, I have longed to live and experience life in a different country. I have always been especially interested in exploring Europe in hopes of better understanding the many different cultures that make it such an amazing place. This dream had always been on the back burner, and then in 2011, with the help of my wife, Pascale, and my two girls, Elisabeth and Sarah (8 and 5 years old), we decided to make it a reality.

Carpe Diem (Seize the Day)!

With our family mantra in mind, we picked up, left Montreal and migrated to Paris, France.

As expected, when displacing a family of four from a three-story house to a small Parisian apartment, the move was exhausting and quite chaotic. Almost right off the plane, I started my new job as a ScrumMaster at a telecom company, and meanwhile, Pascale embarked on her new role as “Product Owner” of our household. Our two girls were rapidly immersed into the Parisian lifestyle and school system.

"With our family in mantra in mind, we picked up, left Montreal and migrated to Paris, France."

The next two years flew by at light speed! Before we knew it, it was time to start planning our return to Canada.

Looking back on our initial move to Paris, we wish we had better prepared ourselves and been more organized as a family while facing this major life change. In the face of another move, we began thinking of ways to approach yet another life changing experience.

Our hearts filled with emotions as we started compiling our to-do lists of Post-its that had to be completed before D-day. As the tasks piled up, we started to wonder how we could possibly get all of this done while trying to maintain a balance of work and living a happy life until the end of our European adventure.

What if Scrum Was the Answer to Our Challenge?

Then, one night, we said to ourselves let’s try something different. What if Scrum was the answer to our challenge? In the agile world, we try to leverage experience and failures to improve, so why not use the same approach to our big move?

Having some positive experiences experimenting with Scrum on a non-IT related team, I said to myself, why not take the same approach with my family? So, we gathered in our bedroom with our Post-its and sharpies in hand, and said, let’s create a backlog!

Elisabeth, being the curious one, immediately asked me, “Daddy, what’s a backlog?” I responded by explaining that a backlog is everything we need to do before leaving Paris. Elisabeth quickly asked, “Can I add the Eiffel tower carrousel to the backlog?” Of course, we said yes!

Mom then asked, “Can we also add taking out the trash?” I said yes, of course! Within seconds, everybody was writing valid stories down on Post-its. Sarah drew her story, because she hadn’t learned to write yet: a picture of her favourite Parisian sweets, Pierre Hermé macarons!

In one evening we compiled more than 50 family stories. These stories weren’t perfect by any means. There were no acceptance criteria, no estimations, but the girls were on board, and dare I say it, excited, and that was more than enough!

Next, we asked ourselves: what can we realistically accomplish in a week? Mom wanted to add the entire house cleaning tasks to the backlog. The girls wanted to add all of the fun stuff, and I wanted to add the must-see tourist attractions we hadn’t yet visited.

So we took a small board and made three columns: “To do,” “Ongoing” and “Done.” We negotiated ruthlessly, but ultimately Elisabeth and Sarah got the most stories in (don’t worry! The parents got their revenge in the following iterations ☺). The first iteration was about to begin.

"We had never seen this much work get done so fast, with so much happiness, ease, understanding and visibility!"

The Scrum momentum was on. We agreed upon one-week iterations (sprints) and then took time on the weekends to plan the next iteration. Each morning, we would have a quick gathering (daily stand-up) and the girls were very anxious to move the Post-its around the board. We had never seen so much work get done so fast, with so much happiness, ease, understanding and visibility!

With the Scrum approach, we were able to get the entire apartment-cleaning task list done, administrative tasks complete and some great museum visits in without any conflicts. Scrum was turning out to be a great tool for our family to use when trying to improve clarity and set priorities for big challenges!

We had the joy of experiencing our last days in Paris in a way that we will never forget.

Scrum Was Turning Out to be a Great Tool for Our Family

Back in Montreal, it seemed as though something was missing … It was Scrum! Realising this, we started a new backlog in the basement, and added a cork Scrum board in the kitchen. Our activities are now visible and updated each morning at the breakfast table.

If there’s one overlying factor that we’ve taken away from this experience it’s that we are so proud to be an agile family!




 

The Agile Household: How Scrum Made Us a Better Family

Mike Cohn's Blog - Wed, 08/20/2014 - 20:13

I’m always fascinated by stories about Scrum (or any agile process) being used outside of software development. When Martin Lapointe told me how he and his family used Scrum -- and especially a task board -- to manage their recent relocation from Paris to Montreal, I immediately asked him to share that story. I’m sure you’ll find it as interesting, amusing, and informative as I did. - Mike Cohn

Ever since discovering the “Agile Manifesto,” I have been trying to integrate its core set of values into my day-to-day routines in hopes of improving processes outside of the office environment. With this in mind, my family and I embarked on an agile adventure that produced amazing results we never expected!

Since my childhood, I have longed to live and experience life in a different country. I have always been especially interested in exploring Europe in hopes of better understanding the many different cultures that make it such an amazing place. This dream had always been on the back burner, and then in 2011, with the help of my wife, Pascale, and my two girls, Elisabeth and Sarah (8 and 5 years old), we decided to make it a reality.

Carpe Diem (Seize the Day)!

With our family mantra in mind, we picked up, left Montreal and migrated to Paris, France.

As expected, when displacing a family of four from a three-story house to a small Parisian apartment, the move was exhausting and quite chaotic. Almost right off the plane, I started my new job as a ScrumMaster at a telecom company, and meanwhile, Pascale embarked on her new role as “Product Owner” of our household. Our two girls were rapidly immersed into the Parisian lifestyle and school system.

"With our family in mantra in mind, we picked up, left Montreal and migrated to Paris, France."

The next two years flew by at light speed! Before we knew it, it was time to start planning our return to Canada.

Looking back on our initial move to Paris, we wish we had better prepared ourselves and been more organized as a family while facing this major life change. In the face of another move, we began thinking of ways to approach yet another life changing experience.

Our hearts filled with emotions as we started compiling our to-do lists of Post-its that had to be completed before D-day. As the tasks piled up, we started to wonder how we could possibly get all of this done while trying to maintain a balance of work and living a happy life until the end of our European adventure.

What if Scrum Was the Answer to Our Challenge?

Then, one night, we said to ourselves let’s try something different. What if Scrum was the answer to our challenge? In the agile world, we try to leverage experience and failures to improve, so why not use the same approach to our big move?

Having some positive experiences experimenting with Scrum on a non-IT related team, I said to myself, why not take the same approach with my family? So, we gathered in our bedroom with our Post-its and sharpies in hand, and said, let’s create a backlog!

Elisabeth, being the curious one, immediately asked me, “Daddy, what’s a backlog?” I responded by explaining that a backlog is everything we need to do before leaving Paris. Elisabeth quickly asked, “Can I add the Eiffel tower carrousel to the backlog?” Of course, we said yes!

Mom then asked, “Can we also add taking out the trash?” I said yes, of course! Within seconds, everybody was writing valid stories down on Post-its. Sarah drew her story, because she hadn’t learned to write yet: a picture of her favourite Parisian sweets, Pierre Hermé macarons!

In one evening we compiled more than 50 family stories. These stories weren’t perfect by any means. There were no acceptance criteria, no estimations, but the girls were on board, and dare I say it, excited, and that was more than enough!

Next, we asked ourselves: what can we realistically accomplish in a week? Mom wanted to add the entire house cleaning tasks to the backlog. The girls wanted to add all of the fun stuff, and I wanted to add the must-see tourist attractions we hadn’t yet visited.

So we took a small board and made three columns: “To do,” “Ongoing” and “Done.” We negotiated ruthlessly, but ultimately Elisabeth and Sarah got the most stories in (don’t worry! The parents got their revenge in the following iterations ☺). The first iteration was about to begin.

"We had never seen this much work get done so fast, with so much happiness, ease, understanding and visibility!"

The Scrum momentum was on. We agreed upon one-week iterations (sprints) and then took time on the weekends to plan the next iteration. Each morning, we would have a quick gathering (daily stand-up) and the girls were very anxious to move the Post-its around the board. We had never seen so much work get done so fast, with so much happiness, ease, understanding and visibility!

With the Scrum approach, we were able to get the entire apartment-cleaning task list done, administrative tasks complete and some great museum visits in without any conflicts. Scrum was turning out to be a great tool for our family to use when trying to improve clarity and set priorities for big challenges!

We had the joy of experiencing our last days in Paris in a way that we will never forget.

Scrum Was Turning Out to be a Great Tool for Our Family

Back in Montreal, it seemed as though something was missing … It was Scrum! Realising this, we started a new backlog in the basement, and added a cork Scrum board in the kitchen. Our activities are now visible and updated each morning at the breakfast table.

If there’s one overlying factor that we’ve taken away from this experience it’s that we are so proud to be an agile family!




 

More Than 800 Videos on TVAgile.com

From the Editor of Methods & Tools - Wed, 08/20/2014 - 09:33
TVAgile.com has just passed the mark of the 800 resources available with an Oredev conference presentation that discusses how to foment creative collaboration based on the tenets of improv and open spaces. TVAgile.com is a directory of videos, interviews and tutorials focused agile software development approaches and practices: Scrum, Extreme Programming (XP), Test Driven Development (TDD) , Lean Software Development, Kanban, Behavior Driven Development (BDD), Agile Requirements, Continuous Integration, Pair Programming, Refactoring, … Explore all these resources on http://www.tvagile.com/

Not vs. Not-Now Prioritization Along with Medium-Term Goals

Mike Cohn's Blog - Tue, 08/19/2014 - 15:00

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

In last month’s newsletter I wrote about how we make personal financial decisions in a now vs. not-now manner. We don’t map out must-haves, should-haves, could-haves, and won’t haves. And I promised in this month’s newsletter, I would cover a simple approach to now vs. not-now planning while still accommodating working toward a bigger vision for a product.

I always recommend having a medium-term vision for where a product is headed. I find a three-month horizon works well. At the start of each quarter, a product owner should put a stake in the ground saying “Here’s where we want to be in three months.” This is done in conjunction with the team and other stakeholders, but the ultimate vision for a product is up to the product owner.

A product owner doesn’t need to be overly committed to the vision—it can be changed. But, without a stake in the ground a few months out, prioritization decisions are likely to be driven by whatever emergencies erupt right before sprint planning meetings. Without a vision, the urgent always wins over the strategic.

For choosing between competing ideas for a medium-term vision, I like using a formal approach—that is, something I can explain to someone else. I want to be able to say, “I chose to focus on such-and-such rather than this-and-that” and then show some analysis indicating how I made that decision. I’ve written elsewhere about relative weighting, theme screening and theme scoring—and we have tools on this website for performing those analyses.

But at the start of each sprint, a product owner needs to make the smaller now vs. not-now decisions of prioritizing user stories to be worked on in the next one sprint. Rather than using a formal, explainable approach for that, I advise product owners consider four things about the product backlog items they are evaluating:

  1. how valuable the feature will be
  2. the learning that will occur by developing the feature
  3. the riskiness of the feature
  4. any change in the relative cost of the feature

I do this by first sorting the candidate product backlog items on attribute one, the value of each feature. There’s nothing special about this; it’s how product people have prioritized features for years.

But I don’t stop there. I use items two through four to adjust the now sorted backlog. For the most part, I will move product backlog items up rather than down based on the influence of these additional factors. Let me explain what each factor is about.

The second factor refers to how much learning will occur by developing the feature. Learning can take many forms—for example, a team might learn about the technology being used (“this vendor’s library isn’t as easy as we were told it would be”) or a product owner might learn how well users respond to a new user interface. If the learning that will result from developing a particular product backlog item is significant, I will move that item up the product backlog so it is developed in the coming sprint.pro

As for riskiness, if a given risk cannot be avoided, I prefer doing that product backlog item sooner rather than later so that I can learn the impact of the risk. And so, I will move the product backlog item up into the current sprint. If, however, there is a chance of avoiding a risk entirely (perhaps by not doing the feature at all), I will move that product backlog item out of the current sprint. I’ll then hopefully continue to do that in each subsequent sprint, thereby avoiding that risk entirely.

Finally, some features can be cheap if they are done now or expensive if they are put off. When I see such an item on a product backlog, I will move it into the current sprint to avoid the higher cost of delaying the feature.

By combining the use of these four factors when selecting items for a sprint with a formal approach to establishing a medium-term, three-month vision, you’ll be able to successfully prioritize in a now vs. not-now manner within the context of achieving a bigger goal.

Now vs. Not-Now Prioritization Along with Medium-Term Goals

Mike Cohn's Blog - Tue, 08/19/2014 - 15:00

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

In last month’s newsletter I wrote about how we make personal financial decisions in a now vs. not-now manner. We don’t map out must-haves, should-haves, could-haves, and won’t haves. And I promised in this month’s newsletter, I would cover a simple approach to now vs. not-now planning while still accommodating working toward a bigger vision for a product.

I always recommend having a medium-term vision for where a product is headed. I find a three-month horizon works well. At the start of each quarter, a product owner should put a stake in the ground saying “Here’s where we want to be in three months.” This is done in conjunction with the team and other stakeholders, but the ultimate vision for a product is up to the product owner.

A product owner doesn’t need to be overly committed to the vision—it can be changed. But, without a stake in the ground a few months out, prioritization decisions are likely to be driven by whatever emergencies erupt right before sprint planning meetings. Without a vision, the urgent always wins over the strategic.

For choosing between competing ideas for a medium-term vision, I like using a formal approach—that is, something I can explain to someone else. I want to be able to say, “I chose to focus on such-and-such rather than this-and-that” and then show some analysis indicating how I made that decision. I’ve written elsewhere about relative weighting, theme screening and theme scoring—and we have tools on this website for performing those analyses.

But at the start of each sprint, a product owner needs to make the smaller now vs. not-now decisions of prioritizing user stories to be worked on in the next one sprint. Rather than using a formal, explainable approach for that, I advise product owners consider four things about the product backlog items they are evaluating:

  1. how valuable the feature will be
  2. the learning that will occur by developing the feature
  3. the riskiness of the feature
  4. any change in the relative cost of the feature

I do this by first sorting the candidate product backlog items on attribute one, the value of each feature. There’s nothing special about this; it’s how product people have prioritized features for years.

But I don’t stop there. I use items two through four to adjust the now sorted backlog. For the most part, I will move product backlog items up rather than down based on the influence of these additional factors. Let me explain what each factor is about.

The second factor refers to how much learning will occur by developing the feature. Learning can take many forms—for example, a team might learn about the technology being used (“this vendor’s library isn’t as easy as we were told it would be”) or a product owner might learn how well users respond to a new user interface. If the learning that will result from developing a particular product backlog item is significant, I will move that item up the product backlog so it is developed in the coming sprint.pro

As for riskiness, if a given risk cannot be avoided, I prefer doing that product backlog item sooner rather than later so that I can learn the impact of the risk. And so, I will move the product backlog item up into the current sprint. If, however, there is a chance of avoiding a risk entirely (perhaps by not doing the feature at all), I will move that product backlog item out of the current sprint. I’ll then hopefully continue to do that in each subsequent sprint, thereby avoiding that risk entirely.

Finally, some features can be cheap if they are done now or expensive if they are put off. When I see such an item on a product backlog, I will move it into the current sprint to avoid the higher cost of delaying the feature.

By combining the use of these four factors when selecting items for a sprint with a formal approach to establishing a medium-term, three-month vision, you’ll be able to successfully prioritize in a now vs. not-now manner within the context of achieving a bigger goal.

Now vs. Not-Now Prioritization Along with Medium-Term Goals

Mike Cohn's Blog - Tue, 08/19/2014 - 15:00

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

In last month’s newsletter I wrote about how we make personal financial decisions in a now vs. not-now manner. We don’t map out must-haves, should-haves, could-haves, and won’t haves. And I promised in this month’s newsletter, I would cover a simple approach to now vs. not-now planning while still accommodating working toward a bigger vision for a product.

I always recommend having a medium-term vision for where a product is headed. I find a three-month horizon works well. At the start of each quarter, a product owner should put a stake in the ground saying “Here’s where we want to be in three months.” This is done in conjunction with the team and other stakeholders, but the ultimate vision for a product is up to the product owner.

A product owner doesn’t need to be overly committed to the vision—it can be changed. But, without a stake in the ground a few months out, prioritization decisions are likely to be driven by whatever emergencies erupt right before sprint planning meetings. Without a vision, the urgent always wins over the strategic.

For choosing between competing ideas for a medium-term vision, I like using a formal approach—that is, something I can explain to someone else. I want to be able to say, “I chose to focus on such-and-such rather than this-and-that” and then show some analysis indicating how I made that decision. I’ve written elsewhere about relative weighting, theme screening and theme scoring—and we have tools on this website for performing those analyses.

But at the start of each sprint, a product owner needs to make the smaller now vs. not-now decisions of prioritizing user stories to be worked on in the next one sprint. Rather than using a formal, explainable approach for that, I advise product owners consider four things about the product backlog items they are evaluating:

  1. how valuable the feature will be
  2. the learning that will occur by developing the feature
  3. the riskiness of the feature
  4. any change in the relative cost of the feature

I do this by first sorting the candidate product backlog items on attribute one, the value of each feature. There’s nothing special about this; it’s how product people have prioritized features for years.

But I don’t stop there. I use items two through four to adjust the now sorted backlog. For the most part, I will move product backlog items up rather than down based on the influence of these additional factors. Let me explain what each factor is about.

The second factor refers to how much learning will occur by developing the feature. Learning can take many forms—for example, a team might learn about the technology being used (“this vendor’s library isn’t as easy as we were told it would be”) or a product owner might learn how well users respond to a new user interface. If the learning that will result from developing a particular product backlog item is significant, I will move that item up the product backlog so it is developed in the coming sprint.pro

As for riskiness, if a given risk cannot be avoided, I prefer doing that product backlog item sooner rather than later so that I can learn the impact of the risk. And so, I will move the product backlog item up into the current sprint. If, however, there is a chance of avoiding a risk entirely (perhaps by not doing the feature at all), I will move that product backlog item out of the current sprint. I’ll then hopefully continue to do that in each subsequent sprint, thereby avoiding that risk entirely.

Finally, some features can be cheap if they are done now or expensive if they are put off. When I see such an item on a product backlog, I will move it into the current sprint to avoid the higher cost of delaying the feature.

By combining the use of these four factors when selecting items for a sprint with a formal approach to establishing a medium-term, three-month vision, you’ll be able to successfully prioritize in a now vs. not-now manner within the context of achieving a bigger goal.

Systems Thinking and Capabilities Based Planning

Herding Cats - Glen Alleman - Tue, 08/19/2014 - 04:23

The term Systems Thinking is many times used in vague and unspecified ways to mean think about the system and all will emerge in a way needed to produce value. 

Systems Thinking is a term toosed around many times with little regard for what it actually means and its relationship to Systems Engineering and Engineered Systems.

But systems thinking is much more than that. Systems thinking provides a rigorous way of integrating people, purpose, process and performance and: †

  • relating systems to their environment.
  • understanding complex problem situations
  • maximising the outcomes achieved.¬†
  • avoiding or minimising the impact of¬†unintended consequences.
  • aligning teams, disciplines, specialisms and¬†interest groups.
  • managing uncertainty, risk and opportunity.

†  "How Systems Thinking Contributes to Systems Engineering," INCOSEUK, Z7, Issue 1.0, March 2010.

Related articles A Breathtaking Paper Positive Deviance
Categories: Project Management

How to choose the right project? Decision making frameworks for software organizations

Software Development Today - Vasco Duarte - Tue, 08/19/2014 - 04:00

Frameworks to choose the best projects in organizations are a dime a dozen.

We have our NPV (net present value), we have our customized Criteria Matrix, we have Strategic alignment, we have Risk/Value scoring, and the list goes on and on.

In every organization there will a preference for one of these or similar methods to choose where to invest people’s precious time and money.

Are all these frameworks good? No, but they aren’t bad either. They all have some potential positive impact, at least when it comes to reflection. They help executive teams reflect on where they want to take their organizations, and how each potential project will help (or hinder) those objectives.

So far, so good.

‚ÄúEverybody‚Äôs got a plan, until they get punched in the face‚ÄĚ ~Tyson Surviving wrong decisions made with perfect data

However, reality is seldom as structured and predictable as the plans make it out to be. Despite the obvious value that the frameworks above have for decision making, they can’t be perfect because they lack one crucial aspect of reality: feedback.

Models lack on critical property of reality: feedback.

As soon as we start executing a particular project, we have chosen a path and have made allocation of people’s time and money. That, in turn, sets in motion a series of other decisions: we may hire some people, we may subcontract part of the project, etc.

All of these subsequent decisions will have even further impacts as the projects go on, and they may lead to even more decisions being made. Each of these decisions will also have an impact on the outcome of the chosen projects, as well as on other sub-decisions for each project. Perhaps the simplest example being the conflicts that arise from certain tasks for different projects having to be executed by the same people (shared skills or knowledge).

And at this point we have to ask: even assuming that we had perfect data when we chose the project based on one of the frameworks above, how do we make sure that we are still working on the most important and valuable projects for our organization?

Independently from the decisions made in the past, how do we ensure we are working on the most important work today? The feedback bytes back

This illustrates one of the most common problems with decision making frameworks: their static nature. They are about making decisions "now", not "continuously". Decision making frameworks are great at the time when you need to make a decision, but once the wheels are in motion, you will need to adapt. You will need to understand and harness the feedback of your decisions and change what is needed to make sure you are still focusing on the most valuable work for your organization.

All decision frameworks have one critical shortcoming: they are static by design. How do we improve decision making after the fact?

First, we must understand that any work that is ‚Äúin flight‚ÄĚ (aka in progress) in IT projects has a value of zero, i.e., in IT projects no work has value until it is in use by someone, somewhere. And at that point it has both value (the benefit) and cost (how much we spend maintaining that functionality).

This dynamic means that even if you have chosen the right project to start with, you have to make sure that you can stop any project, at any time. Otherwise you will have committed to invest more time and more money (by making irreversible ‚Äúbig bang‚ÄĚ decisions) into projects that may prove to be much less valuable than you expected when you started them. This phenomenon of continuing to invest beyond the project benefit/cost trade-off point is known as Sunk Cost Fallacy and is a very common problem in software organizations: because reversing a decision made using a trustworthy process is very difficult, both practically (stop project = loose all value) and due to bureaucracy (how do we prove that the decision to stop is better than the decision to start the project?)

Can we treat the Sunk Cost Fallacy syndrome?

While using the decision frameworks listed above (or others), don’t forget that the most important decision you can make is to keep your options open in a way that allows you to stop work on projects that prove less valuable than expected, and to invest more in projects that prove more valuable than expected.

In my own practice this is one of the reasons why I focus on one of the #NoEstimates rules: Always know what is the most valuable thing to work on, and work only on that.

So my suggestion is: even when you score projects and make decisions on those scores, always keep in mind that you may be wrong. So, invest in small increments into the projects you believe are valuable, but be ready to reassess and stop investing if those projects prove less valuable than other projects that will become relevant later on.

The #NoEstimates approach I use allows me to do this at three levels:

  • a) Portfolio level: by reviewing constant progress in each project and assess value delivered. As well as constantly preparing to stop each project by releasing regularly to a production-like environment. Portfolio flexibility.
  • b) Project level: by separating each piece of value (User Story or Feature) into an independent work package that can be delivered independently from all other project work. Scope flexibility.
  • c) User Story / Feature level: by keeping User Stories and Features as small as possible (1 day for User Stories, 1-2 weeks for Features), and releasing them independently at fixed time intervals. Work item flexibility

Do you want to know more about adaptive decision frameworks? Woody Zuill and myself will be hosting a workshop in Helsinki to present our #NoEstimates ideas and to discuss decision making frameworks for software projects that build on our #NoEstimates work.

You can sign up here. But before you do, email me and get a special discount code.

If you manage software organizations and projects, there will be other interesting workshops for you in the same days. For example, the #MobProgramming workshop where Woody Zuill shows you how he has been able to help his teams significantly improve their well-being and performance. #MobProgramming may well be a breakthrough in Agile management.

Picture credit: John Hammink, follow him on twitter

Three Types of Activities

NOOP.NL - Jurgen Appelo - Mon, 08/18/2014 - 13:47
Three Types of Activities

Three types of activities are keeping you busy:

Type 1: Bad

These are the things you should not be doing. They are wasting your time but still you do them. Stop it!

The post Three Types of Activities appeared first on NOOP.NL.

Categories: Project Management

Why Is It Hard To Manage Projects?

Herding Cats - Glen Alleman - Mon, 08/18/2014 - 05:36

In the absence of a control system that provides feedback to the progress to plan, the project is just wandering around looking for what Done looks like. The notion of emergent requirements is fine. The notion of emergent capabilities is not.

If we don't know what capabilities are needed to fulfill the business plan or fulfill the mission need, then we're on a Death March project. We don't know what value is being produced, when we will be done, or how much this will cost when we're done.

This is the role of the project control system. Without a control system there is no way to use feedback to steer the project toward success.

Control systems from Glen Alleman So when we hear we can make decisions wihout estimating the impact of those decisions on the furture outcomes of the project, we'll know to call BS. First not knowing this impact on the decision making process violates the principle of Microeconomics and second there is no way to close the loop to generate a variance signal needed to steer the project to success. Related articles Staying on Plan Means Closed Loop Control Concept of Operations First, then Capabilities, then Requirements Delivering Needed Capabilities What Do We Mean When We Say "Agile Community?" More Than Target Needed To Steer Toward Project Success Getting to done!
Categories: Project Management

The Purpose Of Guiding Principles in Project Management

Herding Cats - Glen Alleman - Thu, 08/14/2014 - 16:02

Five principles

A Guiding Principle defines the key criteria for making decisions about the application of a project's Practices and Processes. The Principles provide the project with the foundation to test the practices and processes in pursuit of the project's goals in the most timely and cost-effective way while still meeting essential requirements of business outcomes or mission accomplishment.

In the absence of Principles, the Practices and Processes - while possible the rights one - have no way of being tested to assure they are producing actionable information for the management of the project. 

The common lament of we could be spending time and effort doing something more useful, ignores the fact that those  useful things need to be guided by a higher structure - a holistic structure - of exchanging cost for value. The questions should be are the practices and processes we are applying to this project the proper ones to maximize the efficacy of our funding?

These five principles are the foundation of project success. Success means - in the simplist terms - On Time, On Cost, On Value. Time and Cost are easily defined, Value needs another layer for it to be connected with Time and Budget.

What is Strategy

One approach for Value to to connect the outcomes of the project with the¬†Strategy for the business or the mission.¬†Strategy is creating fit among a company‚Äôs activities. The success of a strategy depends on doing many things well ‚Äď not just a few. The things that are done well must operate within a close nit system. If there is no fit among the activities - in this post, the project management activities - there is no distinctive strategy and little to sustain the project management practices and processes. Project Management then reverts to the simpler task of overseeing independent functions. When this occurs operational effectiveness determines the relative performance of the project management activities and the results of the project itself.¬†

Improving operational effectiveness is a necessary part of management, but it is not strategy. In confusing the two, managers will be unintentionally backed into a way of thinking about competition that drives the business support processes (IT) away from the strategic support and toward the tactical improvement of operational effectiveness.

The concept of fit among functions is one of the oldest ideas in strategy. Gradually, it has been supplanted with new concepts of core competencies, critical resources and key success factors. Fit is far more critical to the success of the project management System. Strategic fit among the project management Practices and Processes and the business processes in which the project is deployed is fundamental not only to competitive advantage but also to the sustainability of that advantage. 

This is the fundation of success for Project Based Organizations

The mechnism for creating this Fit is the Programmatic Architecture of the project. This architecture is the same term used for technical architecture. It is the form of the project, in the same way it is the form of the product or service.

The Five Principles That Establish Programmatic Architecture

These Five Principles and their Practices are...

Principles and Practices of Performance-Based Project Management¬ģ from Glen Alleman Related articles What Is Strategy? Elements of Project Success Why Project Management is a Control System Creating Effective Mission Statements That Have Meaning and Function Performance Based Management Principles First, Then Practice Moving EVM from Reporting and Compliance to Managing for Success Project Maxims How To Make Decisions
Categories: Project Management

Rely on Specialists, but Sparingly

Mike Cohn's Blog - Thu, 08/14/2014 - 15:49

Last week, I talked about the concept of equality on an agile team. I mentioned that one meaning of equality could be all team members do the same work, so that everyone in agile becomes a generalist.

A common misconception is that everyone on a Scrum team must be a generalist—equally good at all technologies and disciplines, rather than a specialist in one. This is simply not true.

What I find surprising about this myth is that every sandwich shop in the world has figured out how to handle specialists, yet we, in the software industry, still struggle with the question.

My favorite sandwich shop is the Beach Hut Deli in Folsom, California. I’ve spent enough lunches there to notice that they have three types of employees: order takers, sandwich makers, and floaters.

The order takers work the counter, writing each sandwich order on a slip of paper that is passed back to the sandwich makers. Sandwich makers work behind the order takers and prepare each sandwich as it’s ordered.

Order takers and sandwich makers are the specialists of the deli world. Floaters are generalists—able to do both jobs, although perhaps not as well as the specialists. It’s not that their sandwiches taste worse, but maybe a floater is a little slower making them.

When I did my obligatory teenage stint at a fast food restaurant, I was a floater. I wasn’t as quick at wrapping burritos and making tacos as Mark, one of the cooks. And whenever the cash register needed a new roll of paper, I had to yell for my manager, Nikki, because I could never remember how to do it. But, unlike Mark and Nikki, I could do both jobs.

I suspect that just about every sandwich shop in the world has some specialists—people who only cook or who only work the counter. But these businesses have also learned the value of having generalists.

Having some generalists working during the lunch rush helps the sandwich shop balance the need to have some people writing orders and some people making the sandwiches.

What this means for Scrum teams is that yes, we should always attempt to have some generalists around. It is the generalists who enable specialists to specialize.

There will always be teams who need the hard-core device driver programmer, the C++ programmer well-versed in Windows internals, the artificial intelligence programmer, the performance test engineer, the bioinformaticist, the artist, and so on.

But, every time a specialist is added to a team, think of it as equivalent to adding a pure sandwich maker to your deli. Put too many specialists on your team, and you increase the likelihood that someone will spend perhaps too much time waiting for work to be handed off.

Note: A portion of this post is an excerpt from Mike Cohn’s book, Succeeding with Agile.

Rely on Specialists, but Sparingly

Mike Cohn's Blog - Thu, 08/14/2014 - 15:48

Last week, I talked about the concept of equality on an agile team. I mentioned that one meaning of equality could be all team members do the same work, so that everyone in agile becomes a generalist.

A common misconception is that everyone on a Scrum team must be a generalist—equally good at all technologies and disciplines, rather than a specialist in one. This is simply not true.

What I find surprising about this myth is that every sandwich shop in the world has figured out how to handle specialists, yet we, in the software industry, still struggle with the question.

My favorite sandwich shop is the Beach Hut Deli in Folsom, California. I’ve spent enough lunches there to notice that they have three types of employees: order takers, sandwich makers, and floaters.

The order takers work the counter, writing each sandwich order on a slip of paper that is passed back to the sandwich makers. Sandwich makers work behind the order takers and prepare each sandwich as it’s ordered.

Order takers and sandwich makers are the specialists of the deli world. Floaters are generalists—able to do both jobs, although perhaps not as well as the specialists. It’s not that their sandwiches taste worse, but maybe a floater is a little slower making them.

When I did my obligatory teenage stint at a fast food restaurant, I was a floater. I wasn’t as quick at wrapping burritos and making tacos as Mark, one of the cooks. And whenever the cash register needed a new roll of paper, I had to yell for my manager, Nikki, because I could never remember how to do it. But, unlike Mark and Nikki, I could do both jobs.

I suspect that just about every sandwich shop in the world has some specialists—people who only cook or who only work the counter. But these businesses have also learned the value of having generalists.

Having some generalists working during the lunch rush helps the sandwich shop balance the need to have some people writing orders and some people making the sandwiches.

What this means for Scrum teams is that yes, we should always attempt to have some generalists around. It is the generalists who enable specialists to specialize.

There will always be teams who need the hard-core device driver programmer, the C++ programmer well-versed in Windows internals, the artificial intelligence programmer, the performance test engineer, the bioinformaticist, the artist, and so on.

But, every time a specialist is added to a team, think of it as equivalent to adding a pure sandwich maker to your deli. Put too many specialists on your team, and you increase the likelihood that someone will spend perhaps too much time waiting for work to be handed off.

Note: A portion of this post is an excerpt from Mike Cohn’s book, Succeeding with Agile.

Seven Principles of Agile Software Development in the US DOD

Herding Cats - Glen Alleman - Wed, 08/13/2014 - 23:36

The Software Engineering Institute is a FFRDC (Federally Funded Research and Development Center). An FFRDC, IDA, is a client.

SEI is focused on helping the DOD improve the development of software.

Here are Pod Casts of the Principles of Agile Development of software in the DOD

  • First Principle¬†- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.‚ÄĚ
  • Second Principle - Welcome changing requirements, even late in development
  • Third Principle - Delivering working software frequently‚ÄĚ
  • Fourth Principle - Business people and developers must work together daily throughout the project.
  • Fifth Principle - Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
  • Sixth Principle - The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
  • Seventh Principle - Working software is the primary measure of progress
Related articles Is Your Organization Ready for Agile? Three Kinds of Uncertainty About the Estimated Cost and Schedule Can Enterprise Agile Be Bottom Up? What Do We Mean When We Say "Agile Community?" Studies, Science, Cybersecurity & Saddam: $888.8M to IDA for its 3 US FFRDCs from 2014-2018.
Categories: Project Management

The Ruckus About DDSTOP Post

Herding Cats - Glen Alleman - Wed, 08/13/2014 - 18:03

OpinionAwhile back I posted about Don't Do Stupid Things On Purpose (DDSTOP). This caused some comments about this being a very Theory-X management approach. The notion of Don't Do Stupid Things on Purpose comes from observinig people DSTOP with other peoples money.

Many might say, people have to experiment, try thing out, test the waters. Yes this is true, but who pays for that testing, trying, experimenting? Is there budget for that in the project plan? May be that this is actually an experimental project and the whole point of the project is to do stupid things on purpose to see what happens. 

I wonder if the experimental work being paid for by the customer were worded like that if it would sound so clever?

Here's some clarity and a few examples of DSTOP in recent years.

  • Install CA's Clarity (a very expensive project management and project accounting system).
    • Apply Earned Value to a large ($250M) Enterprise IT project. Project gets in trouble, we come on board to perform¬†triage and discover that the Program Management Office has been copying ACWP - the Actual Cost of Work Performed - to BCWP - the Budgeted Cost of Work Performed - the Earned Value - then reporting to senior management that everything is going fine.
    • Instead of actually measuring physical percent complete to compute BCWP, they simplied copies the cost of the budgeted work, hiding the actual process
    • That's DSTOP
  • Install TTPro as a defect tracking and help desk ticketing system,
    • Communicate verbally most of the defect repairs dome in development.
    • Lose the traceability between the defect and the fix, so the QA staff can't trace the defects back to their rest coverage suite
    • That's DSTOP
  • Plan the development of several 100 million $ of flight avioncis upgrades for an aircraft that has been upgraded in the past.
    • Build the Integrated Master Schedule around the past performance activities - good idea
    • Resource load the IMS from past performance - good idea
    • Discover that the cost and schedule don't fit inside the stated needs of the customer, so¬†dial the work durations and assigned labor loads to fit the¬†price to win for the RFP
    • Get awarded the control, go over budget, and show up late after 12 months of work, get contract canceled
    • That's DSTOP

So is it Theory X to ask those working on the project and managing the project to stop and think about what they are doing, what decisions are being made - and assess the impact of those decisions? Or should those entrusted with the customers money just go exploring, trying out ideas with the hope that something innovative will come out of it?

When we're assumed to be the stewards of other people's money, they should expect us to behave as those stewards. This means we make decision about the use of that time and treasure is ways that are informed by our experience, skills, and governance model. Doing otherwise means we're not the right people to be spending our customers money, or our customer has a lot of money to spend on us to become the right people they should have hired to spend their money.

Related articles In Earned Value, Money Spent is Not a Measure of Progress! What Do We Mean When We Say "Agile Community?"
Categories: Project Management

People Are Not Resources

My manager reviewed the org chart along with the budget. “I need to cut the budget. Which resources can we cut?”

“Well, I don’t think we can cut software licenses,” I was reviewing my copy of the budget. “I don’t understand this overhead item here,” I pointed to a particular line item.

“No,” he said. “I’m talking about people. Which people can we lay off? We need to cut expenses.”

“People aren’t resources! People finish work. If you don’t want us to finish projects, let’s decide which projects not to do. Then we can re-allocate people, if we want. But we don’t start with people. That’s crazy.” I was vehement.

My manager looked at me as if I’d grown three heads. “I’ll start wherever I want,” he said. He looked unhappy.

“What is the target you need to accomplish? Maybe we can ship something earlier, and bring in revenue, instead of laying people off? You know, bring up the top line, not decrease the bottom line?”

Now he looked at me as if I had four heads.

“Just tell me who to cut. We have too many resources.”

When managers think of people as resources, they stop thinking. I’m convinced of this. My manager was under pressure from his management to reduce his budget. In the same way that technical people under pressure to meet a date stop thinking, managers under pressure stop thinking. Anyone under pressure stops thinking. We react. We can’t consider options. That’s because we are so very human.

People are resourceful. But we, the people, are not resources. We are not the same as desks, licenses, infrastructure, and other goods that people need to finish their work.

We need to change the language in our organizations. We need talk about people as people, not resources. And, that is the topic of this month’s management myth: Management Myth 32: I Can Treat People as Interchangeable Resources.

Let’s change the language in our organizations. Let’s stop talking about people as “resources” and start talking about people as people. We might still need layoffs. But, maybe we can handle them with humanity. Maybe we can think of the work strategically.

And, maybe, just maybe, we can think of the real resources in the organization. You know, the ones we buy with the capital equipment budget or expense budget, not operating budget. The desks, the cables, the computers. Those resources. The ones we have to depreciate. Those are resources. Not people.

People become more valuable over time. Show me a desk that does that. Ha!

Go read Management Myth 32: I Can Treat People as Interchangeable Resources.

Categories: Project Management

Agile Bootcamp Talk Posted on Slideshare

I posted my slides for my Agile 2014 talk, Agile Projects, Program & Portfolio Management: No Air Quotes Required on Slideshare. It’s a bootcamp talk, so the majority of the talk is making sure that people understand the basics about projects. Walk before you run. That part.

However, you can take projects and “scale” them to programs. I wish people wouldn’t use that terminology. Program management isn’t exactly scaling. Program management is when the strategic endeavor¬† of the program encompases each of the projects underneath.

If you have questions about the presentation, let me know. Happy to answer questions.

Categories: Project Management

Hierarchies remove scaling properties in Agile Software projects

Software Development Today - Vasco Duarte - Tue, 08/12/2014 - 05:00

There is a lot of interest in scaling Agile Software Development. And that is a good thing. Software projects of all sizes benefit from what we have learned over the years about Agile Software Development.

Many frameworks have been developed to help us implement Agile at scale. We have: SAFe, DAD, Large-scale Scrum, etc. I am also aware of other models for scaled Agile development in specific industries, and those efforts go beyond what the frameworks above discuss or tackle.

However, scaling as a problem is neither a software nor an Agile topic. Humanity has been scaling its activities for millennia, and very successfully at that. The Pyramids in Egypt, the Panama Canal in central America, the immense railways all over the world, the Airbus A380, etc.

All of these scaling efforts share some commonalities with software and among each other, but they are also very different. I'd like to focus on one particular aspect of scaling that has a huge impact on software development: communication.

The key to scaling software development

We've all heard countless accounts of projects gone wrong because of lack (inadequate, or just plain bad) communication. And typically, these problems grow with the size of the team. Communication is a major challenge in scaling any human endeavor, and especially one - like software - that so heavily depends on successful communication patterns.

In my own work in scaling software development I've focused on communication networks. In fact, I believe that scaling software development is first an exercise in understanding communication networks. Without understanding the existing and necessary communication networks in large projects we will not be able to help those project adapt. In many projects, a different approach is used: hierarchical management with strict (and non-adaptable) communication paths. This approach effectively reduces the adaptability and resilience in software projects.

Scaling software development is first and foremost an exercise in understanding communication networks.

Even if hierarchies can successfully scale projects where communication needs are known in advance (like building a railway network for example), hierarchies are very ineffective at handling adaptive communication needs. Hierarchies slow communication down to a manageable speed (manageable for those at the top), and reduce the amount of information transferred upwards (managers filter what is important - according to their own view).

In a software project those properties of hierarchy-bound communication networks restrict valuable information from reaching stakeholders. As a consequence one can say that hierarchies remove scaling properties from software development. Hierarchical communication networks restrict information reach without concern for those who would benefit from that information because the goal is to "streamline" communication so that it adheres to the hierarchy.

In software development, one must constantly map, develop and re-invent the communication networks to allow for the right information to reach the relevant stakeholders at all times. Hence, the role of project management in scaled agile projects is to curate communication networks: map, intervene, document, and experiment with communication networks by involving the stakeholders.

Scaling agile software development is - in its essential form - a work of developing and evolving communication networks.

A special thank you note to Esko Kilpi and Clay Shirky for the inspiration for this post through their writings on organizational patterns and value networks in organizations.

Picture credit: John Hammink, follow him on twitter

Staying on Plan Means Closed Loop Control

Herding Cats - Glen Alleman - Tue, 08/12/2014 - 00:19

Screen Shot 2014-08-11 at 5.03.33 PMFor most projects showing up on or near the planned need date, at or near the planned cost, and more or less with the planned capabilities is a good measure of success. Delivering capabilities late and over budget is usually not acceptable to those paying for our work.

So how do we do this? Simple actually.

We start with a Plan. Here's the approach to Planning and the resulting Plan.

Planning constantly peers into the future for indications as to where a solution may emerge. A Plan is a complex situation, adapting to an emerging solution. 
- Mike Dwyer, Big Visible

The Plan tells us when we need the capabilities to produce the needed business value or accomplish the mission. The Plan is a strategy. This strategy involves setting goals, determining actions to achieve the goals, and mobilizing resources to execute the actions. The strategy describes how the ends (goals) will be achieved by the means (resources) in units of measure meanigful to the decision makers.

Strategy creates fit among a firms activities. For Enterprise IT, this fit is defined by the relationships between the needed capabilities delivered by the project. The success of a strategy depends on doing many things well ‚ÄĒ not just a few.

The things that are done well must operate within a close nit system. If there is no fit among the activities, there is no distinctive strategy and little to sustain the strategic deployment process. Management then reverts to the simpler task of overseeing independent functions.

When this occurs operational effectiveness determines the relative performance of the organization. ["What is Strategy,‚ÄĚ M. E. Porter, Harvard Business Review, Volume 74, Number 6, pp. 61‚Äď78.]

As successful Plan describes the order of delivery of value in exchange for cost, the inter-dependencies between these value producing items, and the synergistic outcomes from these value producing items working together to meet the strategy.

With the Plan in hand, we can ask and answer the following questions:

  • Do we know what Done looks like in units of measure meaningful to the decision makers?
  • Do we have a strategy for reaching done, on or near the need date, at or near the budget?
  • Do we have the resources we need to execute that strategy?
  • Do we know what impediments we'll encounter along the way and how we're going to handle them?
  • Do we have some means of measuring our progress along the way to provides the confidence we'll reach done when we expect to?¬†

This Post Answers the Last Question

The example below is from our cycling group. The principles are the same for projects. We have a desired outcome in terms of date, cost, and technical performance. These desired outcomes have some end goal. A budget, a go live date, a set of features or capabilities needed to fulfill the business case. 

Along the way we need to take corrective actions when we see we are falling behind. 

How did we know we were falling behind? Because we have a desired performance at points along the way, that we compare our actual performance to. The difference between our actual performance and the desired performance, creates an "error signal" we can use to make adjustments.

Out thermostat does this, our speed control on our car does this, the Close Loop Control systems used for managing our project does this. So replaces the cycling example with writing software for money. The Peleton for the desired performance of our work. In the presentation below, ignore the guy in the Yellow Jersey at the end. Turns out he's a Dopper and an all around bad person to his fellow riders and fans.

The simple problem of schedule performance indices from Glen Alleman So let's look at a project example using the analogy of our cycling group, ignoring Lance.
  • We have a goal of riding a distance in a specific time. This can be a training ride, a century, or a Grand Fondo (timed distance for record).
  • We have instruments on the bike. Strava on the smart phone. Gamin on the bars. Both keeping track of instantaneous speed, time moving, total time. As well an average time over the distance.
  • We know, because we've done this route A 100 times before, or we know because we looked at the coure map, or we know because we have talked about the planned distance for the day - about how fats we need to ride - on average - to get back to the drive on a planned time.
  • Say we're out for our Saturday ride, which is usually a 50 to 65 mile loop from the driveway in Niwot Colorado to Carter Lake south of Fort Collins.
  • As a group we agree our average pace will be 20 MPH. Everyone has some way of measuring their average and instantaneous speed.
  • Over the course, it's never flat, some climbs and descents, change the flat land speed, but the average needs to stay at 20 MPH.¬†
  • When one or more¬†drop off the back, I'm usually one of those, we know what are average is. And instinctively we know how much faster we need to ride to catch up -¬†pick up the pace.
  • But if we were actual racers riding solo -¬†time trial or Triathlon, we'd look at our Garmin to see if we're going fast enough to¬†get back on pace, and come in under our target time.

This example can be related to a project. 

  • We have a target for the end ‚ÄĒ a target set of capabilities, with a need date, and a target budget
  • We have targets for all the intermediary points along the way ‚ÄĒ capabilities over time, budget over time.
  • We know our¬†pace ‚ÄĒ how fast to we have to go, how much cost can we absorb, to make our goal of delivering the needed capabilities on the needed date, for the needed budget.
  • We know the gap between our¬†pace and our¬†needed pace¬†to stay on track ‚ÄĒ with an intermediate desired performance, budget, number of features delivered, stated capabilities ready to be ¬†used, and the actual measures of these, we can develop a¬†variance that is used to product an error signal that is used to steer to the project. This is the feedback loop. The closed loop control system we need to keep the project on plan.
  • From that¬†variance we know how much faster we need to go to arrive on time.

This is Close Loop Control

  • Have a target for the end and we have intermediate targets along the way. These intermediate targets are the feedback points we use to assess progress to date
  • Measure the actual value of whatever variables we need to provide visibility to the project's performance. This can be cost, schedule, performance. But it can be other attributes of the project. Customer acceptance. Market place feedback. Incremental¬†savings.
  • Determine the variance between the plan and the actual.
  • Take corrective action to close the gap to get back on target ¬†or get within the variance tolerance.
  • Repeat until project ends.

You're cruise control does this about every 10 milliseconds. You Nest thermostat does this slower, but still less than a minute. To know how often you need to sample your progress against plan, answer this question

How long are you willing to wait before you find out you're late? Sample at ¬Ĺ that time.

This is called the Nyquist Rate, one of the starting point for all the process control software I wrote in my youner days for flying and swimming machines. But it's a good question to ask on all projects as well.

Related articles Is There Such a Thing As Making Decisions Without Knowing the Cost? Time to Revisit The Risk Discussion Can Enterprise Agile Be Bottom Up? Process Improvement In A Complex World Why Project Management is a Control System If you want to pretent you're a Pro, then starting acting like one Control Systems - Their Misuse and Abuse Seven Immutable Activities of Project Success More Than Target Needed To Steer Toward Project Success
Categories: Project Management