Round Pegs and Round Holes
Why My Company Is "Round Peg Management"

Driving a square peg into a round hole is a great analogy to what happens in many companies' product development. Marketing does their best to create a MRD that they believe defines the the competitive marketplace and product requirements document. Once it has been reviewed inside the department it is thrown over the wall to development/engineering.

Development then digests what the MRD asks for and begins to interpret that into a product definition they understand. Hopefully, a good Project Manager will breakdown the work, resources and financial support needed to create the product in a timely manner.

But all too often the product doesn't end up making anyone happy. And the finger pointing usually sounds like this...

"Marketing this thing is going to be like pounding a square peg into a round hole. We are going to have to do something clever to shave the corners off of this." (Product Marketing)

"We don't need marketing's input. We talk to the customer. We know what they want." (Development)

Most of the problem can be solved with good communication and leadership.

That leadership can come from the project manager, product manager, the project sponsor or any other stakeholder who passionately wants to see better results that make both marketing and development proud of the outcome; and companies more competitive and profitable. And, that's what I do.

Kanban (Japanese for "Billboard")

At a recent conference in Austin the presenter reviewed the basics of Kanban project management. Some in the audience, perhaps PMPs, immediately asked how you report your progress? What about earned value? The answer, Kanban portray's earned value not in numbers but visually evident. Take a look at this Kanban board:   (hover to expand)

Kanban Board

You can see the state of all the tasks on the board easily. Six are pending and haven't started, and five are ready to deploy. And that is a big advantage of this technique. Like SCRUM it is easy to see the status tasks on the board and what needs to be done next.

Perhaps the best part of Kanban is how simple it is. You can give an overview to an entire corporate division in a couple of hours and more detailed training to execs and functional managers in a day. The rest can be absorbed by the team as the Kanban Coaching Professional leads.

Basic Principles

  1. Start with what you know
  2. Agree to pursue incremental, evolutionary change
  3. Respect the current process, roles, responsibilities and titles
  4. Encourage acts of leadership at all levels

Core Properties

  1. Visualize the workflow
  2. Limit WIP (work in progress)
  3. Manage flow
  4. Make process policies explicit
  5. Improve collaboration (using models & the scientific method)

Want to know more? Google a tutorial or check MeetUp and Eventbrite for Kanban groups in your area. Agile Austin has a three Saturday hands-on class that starts September 12 which is now sold out, but there will certainly be more classes in the future. There website is

PMBOK Input and Output Flow

Often guide books for passing the PMP exam focus on the same organizational diagrams as the PMBOK itself.  One guide does a good job of showing the sequence of processes, but I’ve never seen an attempt at making sense out of the flow of information between processes in a holistic way.  I think that taking this view makes it easier to understand why processes have specific inputs and outputs and understanding is a great way to help you remember them for the exam.

Work Performance Data, Information and Reports

The PMBOK says data is raw and information is contextualized.  It also says reports come from a gathering of information to create a document meant to support action.  Generally, that action is embodied in a Change Request. Take a look at this diagram:   (hover to expand)

Notice that quite logically Work Performance Data measurements are collected in the Direct and Manage Project Work. Also logically, it is in the Control processes where the data is contextualized by comparing it to Requirements Documents (Scope), the Project Schedule, Project Funding Requirements, Quality Metric and Checklists, Communications Plans, Risk Management Plans, Procurement Plans, Stakeholder Plans and logs.

But the Monitor and Control Project Work is where the various pieces of information are brought together to create reports.  These reports are meant to support the decision making process of Perform Integrated Change Control Management.  It is in the latter process that the Reports are used to add context to the Change Requests that come from all the Control processes.

I Love High Tech

Don't miss my latest article on my Tech page. It's about how industry giants Oracle and Amazon are rolling their own ARM-based processors.