What You Need Is Some Kaizen

While sitting in a governance meeting the other day, I heard how (before I joined the team) a vendor brought in some high paid six sigma black belts to try to bring the vendor governance workflow in line with my client's governance workflow.  My client wasn't sure what they got out of the deal, but if you have a black belt in something, it should be good...right?  Because this venture proved fruitless, the vendor announced, "what you need is kaizen!"  That may be what they said, but it's not what my client heard. This was paraphrased by one of my client's team.  In trying to understand what she was saying, we had a quick back and forth that went a little something like this:

The vendor said there was something that would fix everything. Cry Pan or Pie Pan or something like that.I looked at her and asked, do you mean "kaizen"?Her eyes got really big and she then started to matter-of-factly point at me. That's it! That's it! Now, what does it mean?I said it just means improvement or refinement.She looked disappointed. That's it?Yep, that's it.

Now, I know it's not that simple.  There are no silver bullets.  I do believe in using refactoring or refinement to get you where you need to be, but that's going to be another post.  This post is more of a shame on you post.  Anyone out there who uses a new term, particularly one in a foreign language without explaining it first, shame on you!  Anyone out there who proposes there are silver bullets in project management, shame on you! And, anyone out there who proposes there are silver bullets in project management, uses a new term to label it, AND charges a lot of money for it, shame on you!

I strongly believe approaches like Agile, Kanban, and others bring a lot of potential value to programs.  Customers don't need snake-oil nor do they need silver bullets.  What we have here is, a failure to communicate.

I was thinking, maybe I should start a practice and say it will solve all your problems.  I can call it Verbesserung.

Any takers?

Snow Removal From an Agile PM Perspective

This weekend, our house at the lake received about 30 inches of snow.  It was pretty overwhelming.  Our HOA at Lake Linganore did a very good job and I'm going to tell you why.  Two significant snowfalls ago, we waited 2 days before we saw the first snowplow.  We didn't hear anything out of the HOA.  Days later, the residents got an email from the HOA saying threatening telephone calls and emails  didn't help and to please refrain from doing it in the future.  They believed they did the best they could with the resources they had. I thought they could have done better.  I sent a very pleasant email to the HOA thanking them for their efforts.  A few days later, I sent a followup email with a proposal:  At the next snow storm, I recommended the HOA send out emails, informing the residents of the progress being made.  Whenever I don't like how a product or service was provided to me, I try to offer constructive feedback.  The next storm came, and this time, so did the emails.  There were only a few but they were very clear.  They outlined the priorities of the snow removal.  Main arteries were of highest priority.  The side streets would be tended to when they could.  This time, some residents got stuck before making it to their homes.  They abandoned their vehicles, and unfortunately, a group of vehicles got hit by a snowplow.

Though it took a few days, the HOA came and plowed us out.  Other than those who had damaged vehicles, the tone in the neighborhood was very much improved.  We understood the priorities and respected them.  The communications is what we valued the most.

This weekend, we had an even bigger storm then the last.  This time, the HOA revised their process.  We got emails a day before the snow arrived.  They advised us to get off the roads by a certain time and identified where to park to avoid getting hit by a plow.  We were also provided a list of the highest priorities in order of importance and grouped by need to have and want to have.  Lastly, we received regular emails notifying us of progress or impediments and who could expect to be plowed out next.

Here are a few successes

• They listened to customer feedback
• The process was refined, based on user feedback
• A list of objectives was made and circulated, identifying items of greatest value
• Regular communications

We received a status report this evening.  In it, we were advised another storm is on its way.  Though the community will be completely plowed by the time it arrives, we were assured the HOA will keep us informed. They added, snow removal operations will be reviewed to see what went right and what when wrong this time around and apply those lessons learned to the next storm.

Did your snow removal go as smoothly this time around?

I would love to hear your comments or stories.

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

Seeing Value From The Customer Perspective

I recently sat in a meeting between a vendor and client, where the client was attempting to communicate their need to route new work deliverables to an existing Change Control Board (CCB). The contractor came back and said they believed the CCB in this case would not provide value and perhaps it should be bypassed.

Note to all vendors: Just because a process does not appear valuable to you, it does not mean the process does not provide value. The use of the CCB provides a (formal) control point helping to prevent unauthorized work and cost overruns. This goes further then just having a client billed for unauthorized work. Any work done without prior authorization has a risk of negatively impacting project schedule, cost, or quality. The mere act of doing unauthorized work impacts the scope.

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.

If you think you need to deviate from a documented or understood process, rewrite your process to account for the deviations. If you are unwilling to change your documented process, the deviation is unworthy of being done.

I created the Visio diagram (above) a few months back to help both the customer and vendor visualize what we were trying to accomplish.  The challenge was implementing Scrum in a very formal and controlled environment.

I certainly recognize many don't have such a formal process.  Instead of CCBs, you may call them Product Backlog Review Meetings.  Counter to this, you may have a very fluid and simple software development life cycle (SDLC).  If so, you still need to understand your process and you still need to communicate with your customer.  Understand what their highest priorities are and deliver.

Pillar Technology is Hiring

Pillar Technology is ramping up several large projects in Columbus, OH and Detroit, MI. They are in need of a bunch of people and have opportunities at many different experience levels. They are looking to hire immediately and will entertain people who want to work 1099, W2 hourly, or become full time employees. Pillar's strength is the quality of their people and are pretty selective about who they bring in. They are looking for people that are technically excellent, have great communication skills, and will fit in well to the Pillar culture. Go to Mike Cottmeyer's blog for more details.

To be considered for their technical positions, you need to be an experienced Java developer or technical tester and you MUST have experience with TDD.   Other skills they are looking for are:

• Jboss Portal
• Portlet Specification
• XML Jibx parser
• Rest
• Strong UI / JSP experience
• Maven
• Team City
• EasyMock

The more of these you have the better.

Need more information?  Of course you do! Go to Mike Cottmeyer's blog for more details.

My Merge of GTD and Kanban

I'm not going sit here an boast of being some kind of expert on Kanban or guru of personal productivity.  I'm just a Project Manager/Leader who is always keeping his eyes and ears open for newer or better ways to manage time or work.  I believe you should always try to eliminate non-value-added processes, resulting in a positive impact of customer satisfaction, while reducing support costs.  How do you do that?  You get it done as effectively and efficiently as possible. I recently completed Getting Things Done by David Allen.  It was an interesting book.  Though I use paperless processes to "get things done", David offered one bit of advice that resonated with me.  To advance a task or activity to more of an actionable conclusion, he said to ask "What's the next action?"

This parallels what I do with my Kanban (task) board.  I currently have 4 columns:  Backlog, Work In Progress (WIP), Blocked, Done.  When a prioritized task can not be worked, I put the task card (user story) in the "blocked" column.  I then ask myself the question.  What's the next action? Without asking yourself that simple question, your task may be blocked longer than necessary.  You have to understand there may be 3 or 4 steps you need to complete before you can unblock your task and get it back to WIP.  So, ask the question.

As to not ignore the obvious, I recommend you write your tasks in a standard user story format.As a [perspective], I want to [activity], so I can [desired outcome]

It doesn't matter if you use a physical or virtual Kanban (task) board.  I recommend following 3 simple rules:

1. Keep your tasks visible

2. Keep your tasks limited

3. Keep your tasks actionable

Management Team Wants Versus Needs

Maslow

Mike Cottmeyer of Leading Agile wrote an excellent post, posing a question: Why wouldn't a management team embrace a set of methodologies so focused on giving them what they need the most? I took a few minutes to digest the question and then compared it to my prior experiences implementing Agile on a management level.  Though I have seen the desire of a management team to embrace Agile, allowing more value to be delivered, I also saw them take pause and throw up roadblocks. At the moment they believed the top-down command and control structure would be weakened by bottom-up empowered teams, delivering value suddenly didn't appear to be as important. Though I appreciate the necessity of a management team to provide strategic vision, I believe tactical implementation should be left to those outside the group. The hierarchy of wants, not needs, for the management team differs from the implementation team, if we want to admit it or not.

The key question asked is why wouldn't a management team embrace a set of methodologies or approaches so focused on giving them what they need the most? My answer is I believe it is because delivering value is NOT necessarily what they WANT, it is what they NEED.

My First Year In A Directive PMO

Today I realized I've been supporting and advising a Federal Government PMO for a whole year.  Prior to that, I was the Manager of Software Engineering at an online company that had recently gone public.  I was the sole PMP (Project Management Professional) and  sole Agile Evangelist. Upon my leaving that company, I told my superiors they really needed a PMO if they wanted to offer consistent results, measurable improvements, and increase stakeholder satisfaction.  It was hard at first to shift gears, away from a private profit-driven organization, to Federal governance-driven organization.  At the private company, it was all "being creative" to meet unrealistic goals set by those not versed in best practices.  Since there were no other PMPs, I felt like the lone sheriff in the Wild West.  Now that I'm dealing with the government, I'm surrounded by other PMPs.  There is policy, process, and governance.  Everyone knows their jobs very well.  They know best practices. So you can differentiate the type of PMO I work in compared to others, I've included the 3 basic types below with their definitions.

There are 3 basic types of Project Management Office (PMO) organizations are [1] supportive, [2] controlling, [3] directive.

1. Supportive PMO generally provides support in the form of on-demand expertise, templates, best practices, access the information and expertise on other projects, and the like. This can work in an organization where projects are done successfully in a loosely controlled manner and where additional control is deemed unnecessary. Also, if the objective is to have a sort of 'clearinghouse' of project management info across the enterprise to be used freely by PMs, then the Supportive PMO is the right type.

2. Controlling PMO has the desire to "reign in" the activities - processes, procedures, documentation, and more - a controlling PMO can accomplish that. Not only does the organization provide support, but it also REQUIRES that the support be used. Requirements might include adoption of specific methodologies, templates, forms, conformance to governance, and application of other PMO controlled sets of rules. In addition, project offices might need to pass regular reviews by the Controlling PMO, and this may represent a risk factor on the project. This works if a. there is a clear case that compliance with project management organization offerings will bring improvements in the organization and how it executes on projects, and b. the PMO has sufficient executive support to stand behind the controls the PMO puts in place.

3. Directive PMO goes beyond control and actually "takes over" the projects by providing the project management experience AND resources to manage the project. As organizations undertake projects, professional project managers from the PMO are assigned to the projects. This injects a great deal of professionalism into the projects, and, since each of the project managers originates and reports back to the Directive PMO, it guarantees a high level of consistency of practice across all projects. This is effective in larger organizations that often matrix out support in various areas, and where this setup would fit the culture.

Definition Source:  http://ezinearticles.com/?expert=John_Reiling