Efficiency Order vs. Value Order

I’ve been meaning to write a comparison of Waterfall and Agile software development, as well as the truths in the PMBOK. Until then, I just want to point out one key difference: efficiency order vs. value order.

This is my own terminology, but “efficiency order” and “value order” seem to be the two most reasonable responses to the question, “In what order will work be performed?” Work can be ordered according to the value generated, such that the highest priority work is accomplished first. Or work can be ordered according to the sequence with the least waste. Value order puts building a submarine hull before installing sonar, since submariners can live without sonar, but not without a hull. Efficiency order might install sonar before the hull is complete if doing so requires less labor and improves the schedule. Continue reading “Efficiency Order vs. Value Order”

Efficiency Order vs. Value Order

PMBOK (5th Edition) Inputs, Outputs, Tools, & Techniques

Going through the various processes in the PMBOK (5th Edition), I’m realizing that what I really need to pay attention to isn’t the list of processes, but what is involved in all of them. The repetition of the inputs, tools, and techniques is not how I like to think about these things. So I’m putting together the index below. This is mostly for my reference, but I’m putting it out into the Internet in case anybody else stumbles across this in their search for information on the PMBOK (5th Edition).


Continue reading “PMBOK (5th Edition) Inputs, Outputs, Tools, & Techniques”

PMBOK (5th Edition) Inputs, Outputs, Tools, & Techniques

2, 24, 8, 11, 2 and 6, 6, 7, 4, 3, 4, 3, 6, 4, 4

I’m taking a course right now to prepare for the PMP exam. One of the things we’re working to memorize is the categorization of 47 processes into knowledge areas and process groups. Those categorizations form a grid. Memorizing the number of processes in each column and row really helped my table recreate the grid from memory and impress the instructor.

In addition to those arbitrary sequences of numbers, I have a few additional observations about the distribution of processes according to PMI:

The Initiating process group includes only two processes: developing the project charter (authorizing the project) and identifying stakeholders. These make sense, since before the project manager even gets involved, somebody figured out that they wanted the project to occur, and they had some idea about who is involved in some way. Once the project manager has these in hand, the project planning can start.

The Closing process group includes only two processes: closing project work and closing procurements. The distinction here is between the value generated by the team itself and the value acquired from an outside source.

There are four knowledge areas that have nothing in the Executing process group, and they are the ones that are essentially the project constraints and risks to them: Scope, Time, Cost, and Risk. These each have a large number of Planning processes and one Control process. Scope has the extra validate process under Monitor & Control to ensure that the project resulted in what was promised.

The one knowledge area with no Monitor & Control process is the Human Resource one. This is presumably because monitoring and controlling is about ensuring that your personnel are accomplishing the project as expected within the specified constraints, and thus one in this intersection would be redundant.

Each of the knowledge areas that have at least one Executing process have only a single Planning process: Integration, Quality, Human Resource, Communications, Procurement, and Stakeholder.  Half of these are about the actual accomplishment of work (HR, Procurement, and Stakeholder). The other three are the core of what a project manager does: coordination (Communications), management (Integration), and oversight (QA).

More memorization tomorrow. Good night.

2, 24, 8, 11, 2 and 6, 6, 7, 4, 3, 4, 3, 6, 4, 4

Team Charter – DC SUG – “Are We Done Yet?”

I attended the “Are We Done Yet?” meetup of the DC Scrum Users Group last night. @RichardKCheng did a good job as the trainer. His slides are available as a PDF.

The Team Charter is the team’s self-realized, self-authored norms for how they work, unlike the Project Charter that is handed down from on-high. This includes things like the schedule, definition of done, project understanding, and team rules. There’s no reason I can’t write one up for our team tomorrow.

Some of the stories told and questions ask definitely point to other teams needing a Team Charter more than my team does. We’re already on board with timeliness and professionalism, and we have a decent Definition of Done. Even so, it certainly won’t hurt. Rules for ending horseplay, being available during core hours, and paying attention during meetings are only necessary where the team doesn’t already do these things.

For the “Definition of Done” and “Definition of Ready” themselves, Richard spoke to defining these at various levels:

  1. Ready to Start
  2. Project Backlog Item (PBI)
  3. Sprint
  4. Release

The “Definition of Ready” is essentially the “Definition of Done” for “Getting a User Story/Requirement Ready.” The backlog should be prioritized and refined before Sprint Planning occurs so that there is a supply of PBIs that are Ready. Richard recommended having a refinement meeting several days before Sprint Planning and then having a developer review the PBIs help get to this Ready state.

One of the key recommendations of the night, which should be obvious once you understand the principles of short feedback loops is that the more things you put off doing until the Release level, the greater your risk of failure. As much as you can while being efficient, move activities from the Release level to the Sprint level, and from the Sprint level to the PBI level.

Maybe security scans are onerous and time-consuming, but there could be ways of running part of the scan every Sprint, which thus gives the team the opportunity to address the findings much earlier.

While multiple weeks of regression testing can’t, by definition, be performed every two weeks, creating automated tests (i.e. Coded UI Tests) can permit you to get much of the value at the Sprint or even the PBI level. Why not run the automated tests after every check-in?

All in all, a good meetup, but mostly a confirmation of what I suspected.

Team Charter – DC SUG – “Are We Done Yet?”