What is an A3

An A3 is more than an 11 x 17 inch piece of paper that is structured into several sections and not all A3's are created equal. An A3 is a structured problem solving and continuous improvement approach, first employed at Toyota and typically used by Lean manufacturing practitioners. What your A3 looks like depends upon the situation. The example below consists of the following pattern, as part of an Agile Transformation:

Current Situation & Problem

Root Cause Analysis / Conclusion

Goal

Corrective Action

After we agree on the four steps, we're going to implement the correction action and then verify the results. The content of an A3 follows the logic of the Plan-Do-Study-Act (PDSA) cycle. What I want you to take away from this blog post is not so much TQM, PDSA, and A3's, as much as how you could benefit from them when doing an Agile transformation or any kind of process improvement.

When doing an Agile Transformation, I'm going to always cycle back to 3 core goals.

Form complete cross functional teams

Build backlogs

Deliver working tested software

Anything that gets in the way of doing these is an impediment that has to be removed. The example I have above describes how a team is under-committing each sprint. We're using a story point completion ratio to know if the team is delivering working tested software. We're going to use this single page to have a shared understanding with our client and agree on a course of action. Now, I'm not saying you have to use this template. If you can remove an impediment informally, by all means, do it! But, to make sure my client agrees there is a problem that needs to be prioritized and addressed, this is an effective tool and it's pretty lightweight. You may also notice I don't call this an A3 on the actual example. I'm going to call it an Action Report so my client feels comfortable with common language and I don't need to distract them by introducing Lean terminology. When I say "A3", there are certain expectations. Let's not get hung up on that and just call it an Action Report going forward.

Flow of the Action Report

You'll notice that I structured my Action Report so that your eyes will be drawn to sections. I want to compare 1 and 3 (Current Conditions and Goals) and 2 and 4 (Root Cause Analysis/Conclusion and Corrective Action). This allows a transformation consultant to note impediments and identify root causes independently but then be prepared to collaborate with the client on goals and corrective actions. I'm going to stress this again. We're only going to go through this process if the consultant can't resolve the issue informally. If not, he or she will need to collaborate with the client to confirm the goal and agree on an appropriate action. The consultant doesn't do all of this in a vacuum. When looking at action (or A3) reports used by others, I've seen them identify the goal prior to looking for root cause. From my experience, if I'm required to identify the goal before moving forward, this may create an unnecessary delay. If I don't think something is right, I'm going to start investigating right away and then circle back with the client to validate their goal. But, I'm not going to stop and wait to be told what their goal is before beginning to look for root cause. I don't want to stop until my personal curiosity is satisfied. Also, I'm not saying to not collaborate with the customer. I'm saying keep moving forward on multiple fronts and to circle back at the first logical opportunity.

Current Conditions

We have several opportunities during the transformation to get this information. It could be, we just completed a formal assessment of the team or organization. Maybe we just reviewed metrics of the team or organization. Maybe I just walked out of a really long and unproductive meeting. Whatever we did, I'm looking for some kind of objective criteria or indicator to describe the condition.

Root Cause Analysis / Conclusion

In order to propose appropriate corrective actions, we need to identify the root cause of the condition. Avoid using logical fallacies like anecdotal, appeal to emotion, or false cause. I like to use Socratic method or ask the 5 whys to help reach the root cause.

Goals

The goal listed above in the illustration focuses on getting a team's story point completion ratio to 100% +/- 10%. This goal is pointing back to building backlogs and delivering working tested software. By getting the teams to keep their commitments of delivering working tested software regularly, we allow the business to make better commitments to their customers. If we can build that trust and safety within our organizations, we'll start to build balanced systems.

Corrective Actions

Identify corrective actions that is both short term and easy to implement. If the actions are neither, I keep a higher level corrective action around and then break it down so I can incrementally work toward the goal. Personally, I keep my daily activities on a Kanban board. For an overall transformation, I keep the actions and activities in a rolling 90-day plan. This keeps the client informed on what value I've delivered and what value I plan to deliver in the coming weeks/months.

Plan Do Study Act in an Agile Transformation

When doing an Agile Transformation, PDSA is just one pattern to map the approach. Not mentioned in this blog post are the original inputs into the initial coaching plan and 90-day plan. (both of which are collaboratively defined and continuously evolved with the client). But, how do I fit it all together in a high level "plan do study act" process, more emblematic of the original A3 process? I use the following:

Coaching Plan (Plan)

Rolling 90-Day Plan (Do)

Adoption Assessment (Study)

Metrics (Study)

Action Report (Act)

Summary

I hope this provides some insights into how you can take some of the hand waving out of your next (or current) Agile transformation. There are a lot of moving parts and you need the process and tools to keep an eye on your goals and manage progress, without adding so much overhead that you stifle the forward momentum. Let me know if you have questions!

After my little diatribe titled "Project Management Theater" I had a few days to think about the less than stellar status report provided by the vendor to my customer. The more I thought about it, the more I realized the vendor did nothing to meet the unique customer needs. The attitude was Well, you asked for a status report. This shows status. I'm a firm believer that you need to understand who your customer is and then provide status reporting to meet their needs. Even when using a burndown chart for a team, I usually don't show that to a C-Level. I understand that C-Levels (CEOs, COOs, CTOs...) are looking at the business more strategically. For that reason, I offer my 50,000 foot view of the project or program. Two years ago, when I arrived at this PMO, I looked at their Metrics Plan. One of the things that was missing was a summary graph or chart for the Federal Senior Executives (SES). What you see above is one graphical indicator I provided to them. What you do not see in the screen-grab is the associated data, which I made available on subsequent pages.
I'd like to thank Sam Palani over at Around the CHAOS for inspiring me to write this post. His post How Worthy are Your Status Reports nailed it.

Today I'm going to write about (and provide) a free Project Team Organization worksheet to complement the Project Charter Template so many have downloaded. Both files are free for download, modification, and distribution. [Team Organization Worksheet] [Project Charter Template]
When using the Project Team Organization worksheet, note that there are 4 sections: Structure, Roles and Responsibilities, and a Responsibility Matrix, Project Facilities and Resources. I'm going to focus on the first three.

Step 1: Describe the organizational structure of the project team and stakeholders, preferably providing a graphical depiction (organization chart).

Step 2: Summarize roles and responsibilities for the project team and stakeholders identified in the project structure above.

Step 3: Complete the responsibility matrix for each of the project roles. As a graphical depiction of a more detailed perspective of responsibilities, the matrix should reflect by functional role the assigned responsibility for key milestones and activities.

Step 4: Describe the project's requirements for facilities and resources, such as office space, special facilities, computer equipment, office equipment, and support tools. Identify responsibilities for provisioning the specific items needed to support the project development environment. Hey, you're people need places to sit and equipment to get their work done.

With preliminary approval, copy these values into Section 3 of our free Project Charter Template. Upon Project Charter approval, apply the identified team members to activities in Microsoft Project or your selected Project Management application.

Another thing I would recommend is leverage the data from this worksheet in your Communications Management Plan. You've already identified people and their roles or responsibilities. The most important thing to remember is do what makes sense. This planning worksheet isn't required to do a Charter. It's supposed to make things easier for you and lower the risk of not knowing who is on your team and what they are responsible for.

As I look at the logs of the Critical Path website, I notice a trend for what people are searching. Most visitors coming to this site are searching for project management related templates and worksheets. If there is one thing I try to instill in other project managers, it is listen to your customers! That being said, here is a Work Breakdown Structure (WBS) worksheet to complement the Project Charter Template so many have downloaded. Both files are free for download, modification, and distribution. [WBS Worksheet] [Project Charter Template]
When using the WBS worksheet, list the project’s major milestones and deliverables, the corresponding unique identifying numbers, and the target dates for delivery. This list should reflect products and/or services delivered to the end user as well as the delivery of key project management or other project-related work products.

With preliminary approval, copy these values into Section 3.2 of our free Project Charter Template. Upon Project Charter approval, copy the values from the major milestones column into Microsoft Project or your selected Project Management application and begin creating the activity list (decomposing).

When you are about to initiate a new project, you should capture the basics of project information. If you don't, you're walking into a minefield. Even before you write up a charter, you should be able to answer the following:
Problem (or Opportunity) Statement -Describe the business reason(s) for initiating the project, specifically stating the key business problem or opportunity

Project Description - Describe the approach the project will use to address the business problem

Project Goals and Objectives - Describe the business goals and objectives of the project. Refine the goals and objectives stated in the Business Case (which you should also have)

Project Scope (Requirements) - Describe the project scope. The scope defines project limits and identifies the products and/or services delivered by the project. The scope establishes the boundaries of the project and should describe products and/or services that are outside of the project scope.

Critical Success Factors -Describe the factors or characteristics that are deemed critical to the success of a project, such that, in their absence the project will fail.

Constraints - Describe any project constraints being imposed in areas such as schedule, budget, resources, products to be reused, technology to be employed, products to be acquired, and interfaces to other products. List the project constraints based on the current knowledge today.

If you can articulate these seven areas, you've proven you have at least a basic understanding of what you're up against. If you can not, you better go back and find the answers. It is a lot cheaper to answer a question when the project is still initiating, compared to deep in executing.