Project Management

Direct Playback
Subscribe: Apple Podcast
Check out the podcast on Google Play Music

The SPaMCAST 588 features our interview with Susie Palmer-Trew and Peter Taylor.  We discussed their new book Project Management: It’s All Bollocks!  It was great to meet Susie and renew our conversation with Peter. We talked about the assumptions that the profession of project management makes and why we should challenge those assumptions. The episode has the subtitle (you will discover it ½ way through the interview)  (more…)

Five Color Highligher

Five Different Colors!

Reciprocity is a social norm across societies and in all age cohorts, where a recipient responds to a positive action with another positive action. The concept of reciprocal agreements is part of our socialization that teaches us to share, take turns and give back to those who give to us.  Reciprocal agreements are part of working and playing well with others that we begin learning on the playground and then bring to the office with us. There are many types of reciprocal agreements in a typical agile project. Agreements between the development portion of the team and the product owner(s), between a scrum master and the product owner, between the scrum master and the development portion of the team and finally between the whole team and the stakeholders.  Most of these agreements are informal or are inherited from the twelve principles in the Agile Manifesto. Reciprocal agreements impact how every member of the team and the broader organization interact. There are five common examples of reciprocal agreements that illustrate how important the idea of reciprocal agreements is to a Scrumy version of agile. (more…)

The Software Process and Measurement Cast 345 features our essay on Cognitive Biases and two new columns. The essay on cognitive bias provides important tools for anyone that works on a team or interfaces with other people!

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

SPaMCAST 462 features our interview with Jon M Quigley  We discussed his new book Project Management for Automotive Engineers. Jon co-authored the book with Roopa Shenoy. The book and the ideas in the book are relevant to all types of projects whether they use Agile or not!  A fun and informative conversation!

Jon’s Bio:

Jon M. Quigley PMP CTFL is a principal and founding member of Value Transformation, a product development training and cost improvement organization established in 2009, as well as being Electrical / Electronic Process Manager at Volvo Trucks North America.  Jon has an Engineering Degree from the University of North Carolina at Charlotte, and two Master Degrees from the City University of Seattle.  Jon has nearly twenty-five years of product development experience, ranging from embedded hardware and software through verification and project management.

Jon has written or contributed to a huge number of books, presentations, and articles including:

Project Management for Automotive Engineers ISBN 978-0768080773

Configuration Management: Theory, Practice, and Application ISBN 978-148222935

Contact Jon at:

Here is a promo for my upcoming ITMPI Webinar! (more…)

Product roadmaps come in many sizes and flavors and depending on size and flavor answer a myriad of questions.  There are several common threads through all product roadmaps.  The common threads are:

  1.      Roadmaps are tied to the business strategy.
  2.      Roadmaps answer where are we going.
  3.      Roadmaps answer why we are making the choices we are making.
  4.      Roadmaps are tied to objectives and key results (business outcomes).


Dr Mark Bojeon

Dr Mark Bojeun

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

One my favorite serial interviewees, Dr. Mark Bojeun, returns to the Software Process and Measurement Cast for a third time (we may need to get him a permanent seat at the table soon).  Mark and I discussed the role and impact of project and product visions on the ability to effectively deliver value.  The vision is an important directional statement that can’t be left to chance!   

Mark has last visited the Software Process and Measurement Cast on SPaMCAST 388 to discuss PMOs as a strategic tool and before then on the  SPaMCAST 280 to discuss  his book, Program Management Leadership: Creating Successful Team Dynamics (Kindle version). (more…)

Listen Now

Subscribe on iTunes                   Check out the podcast on Google Play Music

The Software Process and Measurement Cast 397 features our essay on cumulative flow diagrams.  A CFD can help everyone from team members to program managers to gain insight into issues, cycle time and likely completion dates. Cumulative flow diagrams are extremely versatile tools for managing work.

Download the figures that support this essay.

Our second column is a visit to the QA Corner. Jeremy Berriault weighs in on the thorny question of who signs off or approves the results of testing for projects. We discuss some strange behaviors that occur when responsibility and authority for the results of testing are ambiguous.

We also have the debut column from Jon M. Quigley. Jon inaugurates his column with a discussion of whether project risk, scope, and strategy are related.  The short answer is yes, and the longer answer suggests what happens when all of the options are not considered.  Jon is a principle at Value Transformation, LLC ( along with being a teacher, coach, serial author and past guest on SPaMCAST 346. (more…)

Listen Now

Subscribe on iTunes

The Software Process and Measurement Cast 388 features our interview with Dr. Mark Bojeun. Dr. Bojeun returns to the podcast to discuss how a PMO can be a strategic tool for an organization.  If a PMO is merely a control point or an administrative function, their value and longevity are at risk.  Mark suggests that there is a better way.

Mark has last visited the Software Process and Measurement Cast on SPaMCAST 280.  We discussed his book, Program Management Leadership: Creating Successful Team Dynamics (Kindle version).


Deconstructing Value Is Just Like Demolition!

Deconstructing Value Is Just Like Demolition!

Conceptually, value is fairly simple. Value is a measure of importance or worth. This is where simplicity ends and complexity begins. To determine worth and importance we have to understand the difference between the perceived cost and the perceived benefits. Here is the value equation:

Value = (Benefit + Perception) – (Cost + Perception)

Cost, benefits and perceptions are like a suitcase; they are containers with many different things inside. Let’s unpack those suitcases just a bit.

Thinking like a cost accountant is useful when considering the cost component of the equation. The typical costs that are accounted for when costing an IT project include labor, materials, hardware and overhead. Each of these categories could easily be broken down even further. For example, labor can include internal labor (cost of employees) and the cost of contract or outsourced labor. The cost of all labor needs to be considered. I once ran into an organization that only considered external labor when deciding which piece of work should be done. This caused the firm to make economically unbalanced decisions that reduced the value that they delivered to their clients. Far less typical, but no less relevant, costs that need to be assessed when determining value include opportunity costs, business costs and legal and risk mitigation costs. Opportunity costs represent the benefit that would be gained from the work that is foregone to another piece of work. All work has an opportunity cost. Ranking portfolios of possible work by importance is a way of incorporating perceived costs into real costs.

Interestingly, benefits are often far less tangible than costs. Benefits are always predictions of the future, and therefore are more apt to be impacted by perceptions and cognitive biases. Depending on the type of effort, typical benefits often include improvements in market share, cost savings and revenue enhancements. The forecast of benefits is the result of some form of transformational magic that leverages the predicted impact of a change (what will happening if a piece of software is used) and the probability of use (will it be used and how fast will the uptake be). The transformational magic can be incredibly formal based on market research and statistical interpretation or a reflection of gut feel.

The third component of both benefits and cost is perception. Perception means how we regard, interpret or understand a cost or a benefit. Perceptions is the bucket of factors that reflect all of the biases or gut feels with either the cost or benefits. For example, a financial projection might indicate that a feature will deliver $1,000 of value however the might temper that projection based on his or her feeling about the direction of the market. Techniques such as template driven cost/benefit analyses, parametric estimation, planning poker and Delphi estimation try to ameliorate the impacts of some types of less rational perceptions. Overly optimistic estimation of costs and benefits are types of less rational perceptions (read Optimism: The Good and The Bad).

Value is a shorthand mechanism to reflect the difference between benefits and cost based filtered through the perceptions of those collecting and analyzing the numbers. Value is important to concepts ranging from qualifying which feature to work on (part of #NoProjects), selecting user stories for the next sprint (sprint planning) or as prize for getting code into production as fast as possible (#NotImplementedNoValue). These represent only the tip of the iceberg for how value is used in Agile. Without a firm grounding what the word value means it is difficult to ask a product owner what the value of a particular feature is and then help evaluate the answer.


Subscribe on iTunes

This week’s Software Process and Measurement Cast features three columns.  The first is our essay on learning styles.  Learning styles are useful to consider when you are trying to change the world or just and an organization.  While opposites might attract in poetry and sitcoms, however rarely do opposite learning styles work together well in teams without empathy and a dash of coaching. Therefore, the coach and teams need to have an inventory of learning styles on the team. Models and active evaluation against a model are tools to generate knowledge about teams so they can tune how they work to maximize effectiveness.

Our second column features Gene Hughson bringing the ideas from his wonderful Form Follows Function Blog.  Gene talks about the topic of microservices. Gene challenges the idea that microservices are a silver bullet.

We anchor this week’s SPaMCAST with Steve Tendon’s column discussing the TameFlow methodology and his great new book, Hyper-Productive Knowledge Work Performance.   One of the topics Steve tackles this week is the idea of knowledge workers and why a knowledge worker is different.  The differences Steve describes are key to developing a hyper-productive environment.

Call to Action!

I have a challenge for the Software Process and Measurement Cast listeners for the next few weeks. I would like you to find one person that you think would like the podcast and introduce them to the cast. This might mean sending them the URL or teaching them how to download podcasts. If you like the podcast and think it is valuable they will be thankful to you for introducing them to the Software Process and Measurement Cast. Thank you in advance!

Re-Read Saturday News

Remember that the Re-Read Saturday of The Mythical Man-Month is in full swing.  This week we tackle the essay titled “The Second-System Effect”!  Check out the new installment at Software Process and Measurement Blog.

Upcoming Events

Software Quality and Test Management 

September 13 – 18, 2015

San Diego, California

I will be speaking on the impact of cognitive biases on teams!  Let me know if you are attending! If you are still deciding on attending let me know because I have a discount code!


Agile Development Conference East

November 8-13, 2015

Orlando, Florida

I will be speaking on November 12th on the topic of Agile Risk!  Let me know if you are going and we will have a SPaMCAST Meetup.


The next Software Process and Measurement Cast features our interview with Allan Kelly.  We talked #NoProjects and having a focus of delivering a consistent flow of value.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

One Side Or The Other!

One Side Or The Other!

As organizations transition to Agile, teams often ask about how to change from classic command and control project management methods into self-organizing teams. Self-organizing and self-managing teams do not just appear magically. Both the project teams and the organization have baggage that needs to be rationalized and unlearned to progress from needing to be lead to leading themselves. The concepts which have to be learned include the following: measuring business value, team decision-making and sharing the real goals of projects.

Classic command and control project management (which I would classify as minimally collaborative) is based on the premise that the project manager has both unique knowledge and a unique set of skills not held by members of the team.  These skills are thought to revolve around project planning, controlling the people, office politics and status reporting. Certifications, like the PMP®, have been used to encourage these belief.  In this environment the measures of success for projects are often delivering on-time, on-budget and on-scope.

In Agile projects, as discussed in Project Management is Dead, the roles of the classic project manager in Scrum are spread across the three basic roles (Product Owner, Scrum Master and Development Team). A fourth role, the Agile Program Manager (known as a Release Train Engineer in SAFe), is needed when multiple projects are joined together to become a coordinated program.  The primary measures of success in Agile projects are delivered business value and customer satisfaction.  These attributes subsume the classic topics of on-time, on-budget and on-scope. (Note: Delivered value and customer satisfaction should be the primary measure of success in ALL types of projects, however these are not generally how project teams are held accountable.)

As teams learn to embrace and use Agile principles, they need to learn how to make decisions as a team. The decisions that teams need to learn how to make for themselves always have consequences, and sometimes those consequences will be negative. To accomplish this learning process in the least risky manner, the team should use techniques like delaying decisions as late as is practical and delivering completed work within short time boxes. These techniques reduce risk by increasing the time the team has to gather knowledge and by getting the team feedback quickly. The organization also must learn how to encourage the team to make good decisions while giving them the latitude to mess up. This requires the organization to accept some level of explicit initial ambiguity that is caused by delaying decisions, rather than implicit ambiguity of making decisions early that later turn out to be wrong. The organization must also learn to evaluate teams and individuals less on the outcome of a single decision and more on the outcome of the value the team delivered.

Teams, on the other hand, have to unlearn bad habits. For example, teams need to unlearn the habit of relying on others to plan for them. In order to do that, all leaders and teams must have an understanding of the true goals of the project (listen to my interview with David Marquet) and how the project fits into the strategic goals of the organization.

Teams make decisions daily that affect the direction of the sprint and project. The faster these decisions are made the higher the team’s velocity or productivity, and having a solid understanding of the real goals of the project helps the team make decisions more effectively. Organizations need to learn how share knowledge that today is generally compartmentalized between developers, testers or analysts.

The process of learning and unlearning occurs on a continuum as teams push toward a type of collective self-actualization. As any team moves toward its full potential, the organization’s need to control planning and decisions falls away. If the organization doesn’t back away from the tenants of command and control and move towards the Agile principles, the ability of any team to continue to grow will be constrained.  The tipping point generally occurs when an organization realizes that self-managing and self-organizing teams deliver superior value and higher customer satisfaction and that in the long run is what keeps CIOs employed.

Next Page »