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

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

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

The more of these you have the better.

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

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