See Dick See Dick the PM Run

dick_jane_sally

See Dick.See Dick run. Run Dick run.

See Jane. See Jane run. Run Jane run.

You get the idea.

When I was in the first grade, those were the first sentences I remember reading.  I remember being frustrated by this because this isn't really how we talk.  Well, actually, it isn't how I talk.

I suffer from a self-described affliction called over-descriptivitis.  I can't help but elaborate on any and every idea I'm trying to articulate.  I never thought it was a problem.  I merely communicate the greatest level of granular detail to my recipient and allowed them to filter out the extraneous information.  If my wife asks me what I did at work today, I will tell her everything in chronological order.  TMI?

My wife is very forgiving when it comes to me offering more than she asks for.  Sometimes she just puts her hand up and asks, "can I have the abridged version?"  My over-descriptivitis was even addressed in our wedding vows.

I promise I will tell you the time, not how the clock was built.

So,what's the point I'm trying to get across? It's about articulating requirements.  It doesn't matter if you're using shall statements or user stories.  You need to go into enough detail that the person reading it understands your need(s).  After you decide on your format, try to be consistent.

Formal shall statement format: The [activity] shall [desired outcome]

Standard user story format: As a [perspective], I want to [activity], so I can [desired outcome]

Though it may be my over-descriptivitis acting up, I prefer using user stories.  I like the fact that it paints a clearer picture.

How about you?  Do you prefer formal shall statements or user stories? Why?

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?

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. If you're dealing with Waterfall, it's a little more obvious when it's happening.  Some may argue, but I've seen it happen in Agile as well.  I've sat across the table from a vendor and asked, are you prepared to roll back every one of these changes?  Their eyes get big because why wouldn't the client want these changes?  Well, too many times a developer is in the code and they think, while here, why not make this additional change we planned to do next month.  Or, now that I'm here, it makes a lot more sense if I do it like this versus what we originally thought.

In short, Jennifer wrote about goldplating caused by testers. She asked

why is it always the developers who get blamed for goldplating? When you consider the cost of change increases as the project timeline progresses, it becomes evident that, in addition to increasing scope, goldplating by a developer can also be costly. Goldplating by a tester can occur when a tester goes beyond the stated requirements in an effort to produce a “quality” product. A tester may feel that their suggestion would improve the customer experience so they log this in the defect log.  While their suggestion may do exactly what they envisioned, if it was not within the scope of the stated requirements, it becomes a form of goldplating or “feature creep”.   A tester’s job is to ensure that a quality product is delivered, but many testers rely on their own definition of quality rather than using the requirements to define quality...

I’ve seen team members at every stage of the Software Development Life Cycle (SDLC) attempt to goldplate, with the best of intentions. Regardless of where you are in your development process, any time there is a requested change to the baseline, there should be a control mechanism.  I call that mechanism a triage. Be it the customer or a customer representative (Project Manager, Product Owner, or BA), someone needs to vet anything and everything which could impact the baseline.  These changes need to be prioritized and reviewed.  I'm not saying changes should not be made.  I'm saying they need to be properly vetted.  Changes impact the schedule, the budget, and in the end...customer satisfaction.

Without this control point, I think you’re guaranteed to see creep somewhere in your project and you will see it begin to bleed time, money, or both.

Yes, we certainly want to deliver the greatest value to the customer. But, creep increases risk and that’s not value.

Am I just a control freak or do you agree with me?

Free Project Initiation Worksheet

Project Initiation Worksheet

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.

Assumptions - Describe any project assumptions related to business, technology, resources, scope, expectations, or schedules.

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.

[Click here to download a free Project Initiation Worksheet]

Free Total Project Status Report Template

TPS Report

As I study the collection and reporting of metrics and project statuses, I find many reports just do not deliver what they should. I believe there should be a stand-alone deliverable that a project manager is able to provide to a stakeholder at any time, illustrating the total project status.  I created a report and used the name "TPS Report" from the movie Office Space.  I try to interject a little humor into a project, where I can, without raising too many eyebrows.  Because I do not think I should keep all of the good stuff for myself, I hope others will download my free template.  It captures everything from overall project status to schedule, budget, scope, and quality, including a RAG (Red, Amber or Green) status.  What milestones were planned and accomplished?  What is planned for the next period?  Though I believe a subjective narrative does have its place in project reporting, I like the more objective approach.  Give your stakeholders the facts!Please enjoy this free copy of  my Total Project Status Report Template.

Kobayashi Maru for Projects

Without trying to appear to be too much of a geek, I sometimes code-name a project as Kobayashi Maru. For those out there who are not Star Trek geeks, Kobayashi Maru is a test in which command division cadets at Starfleet Academy are presented with a no-win scenario as a test of character. I use the term for a project in which management gets involved and I'm presented with a no-win scenario.  I doubt they are trying to test character. Rather, it's an example of their lack of understanding project management. I'm sure there are PMs out there who have had management redirect resources from your project to others, only to refuse to narrow scope or push out a delivery date. That is a Kobayashi Maru.  Just because I have a PMP®, don't expect me to pull a rabbit out of a hat.  On a previous program, I've looked management in the eye and reminded them that something will have to give.  Narrow scope, extend the deadline, lower quality expectation, or increase the budget.  Do something or this will be a no-win scenario.

Image from : drexfiles.wordpress.com

What is missing from a Cost Performance Report

I recall a very positive meeting where we exposed several non project management team members to a Cost Performance Report (CPR) for the first time. A CPR addresses project performance through a defined period of time in relation to contractual requirements.  The CPR details budgeted work scheduled and performed, actual cost work performed, and the variance in both schedule and cost.  All of this is itemized per Work Breakdown Structure (WBS) element for both the current period and the cumulative to date.  The last values you see are the budgeted, estimated, and variance at completion of the contract. There were a lot of questions as to why one WBS element has a positive or negative cost variance and why it may have a positive or negative schedule variance.  Trying to explain this to those without a project management background can be a challenge.

I was having a sidebar conversation with one team member who could not understand how the element that pertained to him could be both ahead of schedule and below budgeted cost. The answer came from across the room in the form of a question.

"Is there any way this report captures quality?" The answer was no.

That my friends is called Triple Constraint.  We know the Scope, Time, and Cost within this report.  What we don't know is Quality, Risk, or Customer Satisfaction.  That's ok.  This is the CPR, not a Total Project Status (TPS) Report.

By not committing the scheduled time and budgeted dollars to complete the task to a level of quality that meets the customer's expectations, the contractor looks good only on paper.