How to Use an A3 Report

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:

1. Current Situation & Problem

2. Root Cause Analysis / Conclusion

3. Goal

4. 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.

A3 Report Example

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

1. Form complete cross functional teams

2. Build backlogs

3. 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:

1. Coaching Plan (Plan)

2. Rolling 90-Day Plan (Do)

3. Adoption Assessment (Study)

4. Metrics (Study)

5. Action Report (Act)

Inputs and Outputs of an A3 Report

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!

Download a free copy of the A3 Report Template

Meetings: Get To The Point

Upon a brief review of my site analytics, I noticed something striking. For the month of February, almost nine percent (9%) of my page views are for one thing:  Free Meeting Minutes Template Back in March 2009, I wrote a post about helpful tips for running a meeting.  With it was a free copy of my meeting minutes template.  So, I think it's time for a brief refresher with a few updates.

When Hosting a Meeting:

[1] Write out the purpose of the meeting with actionable events in mind. e.g. “Provide an updated status, identifying risks and opportunities, and identify new action items.”

[2] Identify your attendee list but only keep those you can map to the actionable events listed in step 1.  There is a difference between an attendee list and a communications distribution list.

[3] Create an agenda.  Never schedule a meeting without a written agenda. A meeting without an agenda is inefficient and a waste of time.

[4] Identify who will run the meeting and who will take notes. It should not be the same person.  Both people should know their roles before the meeting begins.

[5] Ensure discussion points align to the agenda. If the conversation drifts off topic, recommend taking the discussion to another forum.

[6] End the meeting by having the note taker read back discussion points and the action items. Make sure there is a consensus before the meeting ends.

[7] Send out the meeting minutes within one to two days. Consult your distribution list to ensure all necessary people get a copy.

As a disclaimer, I hate meetings.  Many are unnecessary.  But, when meetings are necessary, get them done as quickly as possible.  Get in, get to the point, get out, get back to work.

Bonus Recommendations:

[1] Start on time. If you don't start on time, you can't finish on time.

[2] Do not schedule your meeting to end at the top or bottom of the hour. I'm a fan of the 22 minute meeting.  Have meetings end a little early.  Some people need to get to other meeting and this will help prevent them from being late.

---

The Critical Path Week in Review

This week I really wanted to turn up the volume of things I wrote about.  I have a lot to say (and write) about project management and if you missed reading my blog on a given day and don't have an RSS feed or follow me on Twitter, you'd have to go searching in the archives to find it.  I don't think that's good enough.  I should make it easy for you to read what I write.  Hopefully, this week in review will help you find something new while you enjoy your coffee or tea.

1/28/2010

Seeing Value From The Customer Perspective

I don’t care if you’re using Agile, Waterfall, or other methods to deliver value.  What is important is you understand your process and what mechanisms provide the greatest value to the customer.  Just because a process does not appear valuable to you, it does not mean the process does not provide value...

1/29/2010

Refine Your Process If You Must Deviate From It

If you’re looking for a free Microsoft Visio template of a Sprint process workflow, which you can edit at will, you can download it here.  As I mentioned in my post Seeing Value From The Customer Perspective, if you think you need to deviate from a documented or understood process, rewrite or refine your process to account for the deviations...

1/30/2010

The Impact Of Social Networking On Project Management

Good leaders do not operate in a vacuum. They exchange ideas and information with people. Offer free information and it will come back to you tenfold. Listen to knowledgeable people and then make a more educated leadership decision... In this post I compared the traditional communication paths and how that process is turned on its ear, thanks to social networking...

1/31/2010

This Is How You Know When To Kill A Project

A personal rant about paper telephone books and how I never realized, until now, who the real customer was. There is a very similar parallel between the newspaper industry and the printed phone book industry.  They both believe or promote the scarcity of information.  That scarcity justifies cost.  To the contrary, we now live with an abundance of information.  That information is freely distributed and reaches a broader audience...

2/1/2010

The December Numbers Are In For PMPs

Yes, the December numbers are in.  December 2009 numbers for Project Management Professional (PMP®) certifications were published and it looks like there will be over 400,000 holding the certification in 2010...

	December Totals
New PMPs (December 2009)	5,403
New PMPs (YTD)	75,107
Total Active PMPs	361,238

2/2/2010

And The Best Methodology Is

I recently commented on two blogs that address similar topics.  Jesse Fewell wants to empower teams to succeed, equip managers to lead, and enable executives to unlock the secrets of high performing organizations.  Jesse wrote a blog post offering the real reasons behind the methodology wars.  It’s an insightful post and I would recommend you go and read it...

The other blog post was from Mike Cottmeyer, someone I turn to on a regular basis to find inspiration and wisdom within the industry.  Mike wrote a blog post asking Why is Agile so hard to sell? Again, it is a very good read and you should set aside some time to read some of his writings...

The Pain Of IE6 And Application Development

There are legacy applications out there that were built on IE6 and it’s not an easy migration.  There are some Agencies which ONLY use IE6 and the users don’t have permissions to install a new browser.  So, what do you do?...

2/3/2010

Updated 10 Step Help To Submit PMP PDUs

All PMPs need 60 PDUs during a CCR cycle so don’t put it off until the last minute.  I document the process on how to claim your require 60 PDUs...

2/4/2010

Using Common Sense With Documentation

Though I really love good documentation, going heavy on it does not guarantee a successful project.  My recommendation is you spend a little time identifying documentation that truly meets your needs.  More importantly, identify documentation that truly meets your customer’s needs...

2/5/2010

Managing Risks and Opportunities

Washington DC is in the process of getting 20-30 inches of snow, over the next 24 hours.  Though I know you can’t foresee all possible issues which may occur over the course of a project, you should make an honest attempt to identify them in order to open a dialog with your stakeholders.  Has weather ever delayed your project or pushed it over budget?...

Using Common Sense With Documentation

Though I really love good documentation, going heavy on it does not guarantee a successful project.  At my last engagement a product manager asked why she had to go back and complete a business case, a feasibility study, and a charter when her team was already several months into development of  the current release.  She was being consumed by back-filling this documentation.  I believe this was a poor business decision by someone higher in the organization.  They did not "get it".  Documentation is nothing more then a communications tool.  When improperly used, a tool will not necessarily give you the benefit you need.  Need to drive in a nail?  You wouldn't use a screw driver, would you?  Then why would you ask someone to use their valuable time and energy to create a document for the sake of creating the document?  Use the appropriate tool at the appropriate time to get the appropriate results.  If there was a 1 year project with a requirement stating there had to be a feasibility study, then you better have one.  You should have done it at the inception of the project.  But, if you have a project that is only 1 month long, use some common sense. My recommendation is you spend a little time identifying documentation that truly meets your needs.  More importantly, identify documentation that truly meets your customer's needs.  You're not impressing anyone with a SharePoint site or filing cabinet filled to the brim with documentation nobody ever looks at.  One good example of a document that provides value is a Project Charter.  I know, there are hundreds of you out there rolling your eyes.  You figure your stakeholders are not going to sign this document (though they should), formally authorizing a project or a phase.  But, this same artifact does document initial requirements that satisfy the stakeholder’s needs and expectations.  Having this document and answering those questions is going to increase the probability of you having a successful project.  Use it as a communication tool!

Since a majority of the search results coming to this website are from people looking for Free Project Management related templates and worksheets, I decided I better give my readers what they are looking for.  You are my customer!  You have expressed a need or want for templates and worksheets.  I should make it my goal to satisfy those needs.

I'm currently working on a new business case template. What will be in it, you ask?

Project Overview

1. Problem Statement
2. Project Description
3. Project Goals and Objectives
4. Project Scope (what's included and what's excluded)
5. Critical Success Factors
6. Assumptions
7. Constraints

Authority and Milestones

1. Funding Authority
2. Project Oversight Authority
3. Major Project Milestones

Project Organization

1. Project Structure
2. Roles and Responsibilities
3. Responsibility Matrix
4. Project Facilities and Resources

Points of Contract

Glossary

Revision History

Appendices

Did I miss anything?  Give me a few days and I'll have it done.

I welcome any feedback or comments.  Just post them below.

Regards,

Derek

Refine Your Process If You Must Deviate From It

As I mentioned in my post yesterday, Seeing Value From The Customer Perspective, if you think you need to deviate from a documented or understood process, rewrite or refine your process to account for the deviations. Merriam-Webster defines process as a series of actions or operations conducing to an end.  If you are unwilling to modify your process, the deviation is unworthy of being done. I've had a vendor tell me they didn't need to document their processes because they were agile.  (Notice the lack of an uppercase A in Agile).  Leveraging Agile concepts does not mean a lack of documented process.  IF the customer tells me they see the greatest value in delivering documentation, what is this vendor going to respond with?  Sorry, we won't deliver value?  If you use Waterfall, you may be used to generating more paper.  You have to consider documentation on a case by case basis.  Some customers have legitimate needs for documentation and other have wants.  Now go back and read that last sentence again.  Needs...Wants...

I personally like to go light on documentation.  What I need and what the customer needs are usually two different things.  That being said, I like to understand the rules (governance) before I start anything.  The Microsoft Visio document I included in my last post was a good example of a high level governance (functional flowchart) document. After completing the flowchart, I then detail each activity in a separate document.  What is the input and output?  Is there a formal deliverable associated with the activity? The idea behind the separate document is you won't need the flowchart to describe the process.  For those who have successfully navigated a SOX audit, you know what I'm talking about.  But I digress.  The flowchart activities I documented are not groundbreaking.  The process in this case is an Agile Scrum process with a few defined quality assurance decisions points.  You do not need to go into the Nth degree to understand this process.  Identify some touch points where the vendor and customer interface.  Identity some decision points.  That's it!

I've done these flowcharts for several customers.  I've created them for both Waterfall and Agile development approaches.  If you're looking for a free Microsoft Visio template, which you can edit at will, you can download it here. I zipped it to make downloading easier.  If you're looking for other free templates or worksheets to use on your project or program, you can download them there.

What do you think?  To document or not document.  That is the question. I welcome your comments or feedback.

Regards,

Derek

1 of 100 PM Related Questions I Ask Myself

Hmmmmm

Question 1: In the hope to help the Project Management industry mature, should project management related templates and worksheets be freely distributed to the project management community or should there be a reasonable fee charged? I am a strong believer in the wisdom of crowds.  If there was a consortium of types with diverse backgrounds in Waterfall, Spiral, RUP, Agile, Scrum, XP... don't you think they could come up with some pretty good stuff?  In this case, all templates would be freely distributed.  I have to admit, the majority of my traffic is from people looking for free templates and worksheets.  It's tempting at times to put them behind a pay wall and ask for 99 cents.

What do you think?

Image courtesy of misallphoto on Flickr

Free PM Templates and Worksheets Page Updated

Though I haven't uploaded any new templates today, I did fix some broken links. Thank you PJ for bringing it to my attention.  The Free PM Templates and Worksheets page has been fixed.  I understand the page should be redesigned so it's easier to see what is available.  Thank you for those who let me know when they find an issue on the site.  Feel free to just add a comment to a page.  I'll get it!

Regards,

Derek

Free Project Charter Template

Project Charter Template

How many times have you started working on a project and don't even have formal authorization for that project to exist?  A project charter is a document issued by the project initiator or sponsor that formally authorizes the existence of the project, and provides the project manager with the authority to apply organizational resources to project activities.  Using this template will put all the cards on the table.  Knowing answers to key areas before you begin will save you time and money. This document includes areas for project overview, authority and milestones, organization, and points of contact.

On your current project, do you know the project oversight authority?  Do you know your critical success factors? Have you documented all of your project roles and responsibilities?  If you used this template, you would increase your chances for success by documenting the basics up front.

MS Word

[Click here to download the free Project Charter Template]