The Critical Path Week Ending February 28

Due to working crazy off hours in preparation for my v1.0 launch, I not only forgot to do a week in review on the 20th, I also missed meeting my writing commitment on the 24th and 25th.  Whatever the excuses, I was feeling a little burned out.  I have to remember this is a marathon and not a sprint.  Writing a daily blog takes a lot of discipline.  Though I have so much to say, it can escape me if I don't get the idea captured quickly.  Wow, it's hard to believe it's almost March.  At least there should be viewer posts about snow removal.

2/26/2010

Putting Things In Perspective

I had mild chest and shoulder pains this morning. I am in the ER waiting to see the doctor. I’ll let you know the outcome and my status shortly...

2/23/2010

Satisfying Needed Scope Versus Wants

There are many templates and means to ensure your project meets the requirements.  But I can’t stress enough how important it is to ensure you’re working to satisfy the requirements (or scope) first...

2/22/2010

The Hateful Cycle of Apathy Hits a Nerve

Have you ever stuck your neck out and get no support?  Did the trust among that team start to break down? I’ve seen it happen first hand and Geoff Crane wrote an awesome post over at Papercut Edge about it...

2/21/2010

How To Prevent Your Project From Hemorrhaging

This post is in response to a post written by Jennifer Bedell on the PMStudent blog about goldplating. Goldplating is very common in application development and can be very expensive...

2/20/2010

How Owners Managers and Leaders Differ

I was asked a very interesting question today, requiring me to stop and think. How do I believe being an entrepreneur and a business owner differ? It’s a very good question because...

2/19/2010

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

2/18/2010

How to Thank a Managed Camel

I was informed I am the winner of the very first Freedom of Speech February (FOSF) giveaway from How to Manage a Camel.  My comments last week on a blog post by Gary Holmes earned me a free copy of the Method123 Project Management Methodology (MPMM™) Professional from their partners at Method123...

2/17/2010

Creeping Ever So Closer To Closure

As my startup project is creeping ever so closer to its closure and the actual launch of the product happens, I’m feverishly completing activities late into the night.  It’s not easy working crazy hours to get this done.  My family goes to bed, I drink a pot of coffee, and get to work...

2/16/2010

Interesting PMI Perspective On Claiming PDUs

...Based on the telephone conversation I had, if you’ve worked as a PM for at least 6 months, you can claim 5 PDUs.  Otherwise, if you are able to say you spend more than 1,500 hours per calendar year in that roll, you also qualify to claim the 5 PDUs...

2/15/2010

Getting Exactly What You Want

I just wrapped up a week long logo design project at 99Designs, with an intellectual property transfer agreement.  Flash back to August 2009, when I was watching Episode 13 of This Week in Startups...

Satisfying Needed Scope Versus Wants

traceability

What is the definition of Requirements Traceability Matrix? It's a table that links requirements to their origin and traces them throughout the project life cycle.  Not everyone uses them. There are many templates and means to ensure your project meets the requirements.  But I can't stress enough how important it is to ensure you're working to satisfy the requirements (or scope) first.  I reviewed a vendor's progress report today and realized the very last task they had on their activity list was requirement mapping.  When asked why it was the last item on their list, their response was the activity wasn't on the critical path.  So, how on Earth were they going to know they were done, if they didn't map the requirements first?  Here they are, at the end of a development cycle, and we're being told the requirement mapping activity is just basically a clerical process. Imagine the frustration I suffered, knowing all too well they may have missed something.  Imagine how expensive it could be, to fix at the end versus the beginning of the development cycle?  I'm not saying the vendor didn't do a lot of work or deliver a lot of product.  Unfortunately, they spent way too much time satisfying the daily wants of a stakeholder and took their focus off the needs of satisfying project requirements in the process.

What do you think?  I'm a being too much of a control freak?

The FedGov Fail Day 3

As we enter the 3rd day of Washington DC being shut down, I ask myself why.  It's 2010, for crying out loud!  You'd think they would find a way to keep things operational.  Just because government employees can't report to physical locations, doesn't mean they can't work, right?  From the OPM.gov website, Federal agencies in the Washington, DC, area are CLOSED. This means...

• Federal agencies in the Washington, DC, area are closed. Nonemergency employees (including employees on pre-approved leave) will be granted excused absence for the number of hours they were scheduled to work. This does not apply to employees on leave without pay, leave without pay for military duty, workers' compensation, suspension, or in another nonpay status.

• Telework employees may be expected to work from their telework sites, as specified in their telework agreements.
• Emergency employees are expected to report for work on time.
• Employees on alternative work schedules are not entitled to another AWS day off in lieu of the workday on which the agency is closed.

---

Now, this post isn't necessarily about government employees, a majority of whom will just stay at home and get paid.  Don't get me wrong, I care a lot about my government counterparts.  Some of them work darn hard and are up late at night keeping things running.  This is about all of us who support the government.  In a day and age when the government needs to be nimble and innovative, I sit here knowing I'm not necessarily going to get to bill an hour of my time, while the Federal agencies in the Washington DC area sit idle.  No, I certainly can't do 100% of what I was hired to do but I have things I could have caught up on.  I have a constant rotation of priority deliverables that arrive in my inbox, ready for my review and recommendations.  I don't need to be on site to read a document about cost and schedule variance on CLIN 123, in order to deliver value.  But guess what, that's exactly the case.  If I'm not physically on site, I have to get special approval to do any work and bill any time.

As Jhaymee (@TheGreenPM) Wilson tweeted today, the recent Snowmageddon in DC brings visibility to the Federal Government's lack of a risk management policy, which includes teleworking.  I believe the policy should include contractors.  My FedGov PMO identified a strategy to keep us operational, in the event H1N1 hit the agency.  The strategy was a mandate from higher in the government.  So why then wouldn't there be a plan to keep us operational in the event of inclement weather?  This just proves, in cases like this, the Federal Government doesn't plan to fail; It just fails to plan.

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