The Hard-Nosed Project Manager

Over deliver

I was reflecting this morning on the “under promise but over deliver” maxim which I believe is attributed to Jack Welch.  What prompted this reflection is a podcast that was discussing the expectations of a pharmacist’s clients; really not project management related.

In my line of work, like many lines of work, we can’t “under deliver” as testing will catch up to us.  If you “under promise”, you simply won’t get the job.  Economics mean that line managers don’t want us to over deliver and again, testing would not allow that either.

I wonder, and I’d like for you to chime in, if it would not be good to over deliver not on scope but on project management and especially on communications.   It may cost a little bit more and not be reimbursable but I believe it would create significant goodwill and give an incentive for repeat business.  Works for me…

What do you think? As always questions and comments are welcome.

Connect with me on LinkedIn. I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network.

 

 

Applies to project management (I think...)

Watch this video and tell me if I’m completely off my rocker…

 

I’m thinking that this applies to project management especially in these hard economic times.  The speaker explains how he uses found objects (COTS software) to attain his goals (scope).  One particularly interesting bit is the ceramic treatment made out of smashed toilet bowls.  I wonder how much it would cost to get the same effect with custom made tiles…

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network.

Risk management is a day 0 activity

This morning I was participating in a Mentisor seminar/roundtable activity on Risk Management and Scope Management.  Both subjects are basic project management topics that often don’t receive the attention they deserve given the mayhem that neglect may cause.  This got me to reflect on a conversation I had a few months ago with a client that got badly burned.

In my line of work system validation is mandatory and very expensive compared with hardware/software/programming costs.  The numbers vary and each of my clients has its own pet number but it is typical to add 170%, 200%, or even 220% to the purchase cost just to account for validation.  In hard numbers this means that a $1M system will cost $2.7M to $3.2M by the time it is validated and rolled out.  If the system is more expensive; you do the math.  It can get scary pretty fast

A side effect of this multiplier is that clients understandably fight scope change tooth and nail.  We do the same; no one wants to be the donkey in a game this pricey.  The title of this post being “Risk management is a day 0 activity”, you are probably wondering where I am going with this?  Well, the wait is over; some best practices related to Risk Management and Scope Management should avoid a lot of wasted money:

• Risks are built in the project approach; a project or product is not a repeat activity and some of this innovation is likely to have unrecognized risks. Recognize this from day 0.

• Avoid Swiss army knife software; there is no software package that does everything well and all those marginal features will still need to be tested and validated ($$$). What is the likelihood that some of these features are putting you project budget or schedule at risk?

• Avoid stakeholder’s pet feature for the same reason as above. I’ve had requests for reports that have the same content but packaged differently; keep only one variant and let the people adapt. There has to be a positive aspect to that Evolution thing.

• If you can’t avoid the two previous points, identify those features that are risky, track their triggers diligently, and the minute those triggers engage let the project sponsor know. You may be able to jettison them before they really hurt the project or at least to minimize their impact.

• Remind your stakeholders that featuritis is costly to implement, to validate, and to live with over the live of the product or system. Remember COBOL, FORTRAN, etc? Systems written in those languages still need to be “fed” years after rollout by old guy like me who will retire eventually.

Don’t tell me that these points don’t ring true and that they don’t represent situation that repeat themselves, with predictable outcomes.  Recognizing and managing risks from day 0 will save you a lot of aggravation and costs.

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.

Gizmos, gadgets or just plain SMART?

More catching up and I landed on this post.  I fail to see how an iPad or for that matter any other hardware gizmo would improve requirements.  In most cases the issue is not with the format but more with the quality of the requirements. 

What about coming up with SMART requirements?

· Specific

· Measurable

· Attainable

· Realistic

· Timely

I think that we may be able to do this without gadgetry.

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkeIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.

Bracketing the target

I like appropriating expressions of my past lives and reusing them in project management.  Bracketing the target is something an artillery observation post crew does; you start shooting for a target and then try to find its actual location by overshooting it, undershooting it, and shooting right and left of it.  Then you deal with it…

In project management the equivalent would be finding the true scope of a project which may be hidden within a large number of fuzzy requirements.  That fuzziness comes from a lack of context, the use of jargon, the piggy backing of requirements left behind from other projects, pet requirements, etc.

As I mentioned in my CHAOS theory post I believe that applying a Pareto law to the set or requirements would remove the 20% that really hurts the schedule and cost of a project and increase risk.  My experience is that when you leave those 20% behind you hardly ever get to include them in future releases; they just weren’t that “required”. 

Looking at it from a slightly different perspective Glen Alleman replied in a comment that at the US DoD, under Secretary Gates, 60% of the needed capabilities "now" are considered much better than 100% (or something near that) later.  This is a very good, very pragmatic approach to projects.

The best practice we’ve been using to get everyone on the same page is to do a prototype, demo it, and then make the necessary adjustments.  This prototype is not a throwaway; it is a rough draft of the end project.  This approach works with software projects as well as “consulting” assignments such as strategic planning.

Using such an approach as always allowed us to identify and then remove fuzziness from requirements.  It is also a great way of working around communication issues brought on by jargon.  The end result our clients and for us is less pain and typically a lower cost, a more accurate schedule, and less risk.

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkeIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.

CHAOS theory

Glen Alleman’s post on the Standish Group CHAOS Reports documents nicely many of the weaknesses of those reports.  Having only three categories doesn’t provide enough granularity, fuzzy definitions for these categories, no access to the base data, small sample sizes, etc. 

You also have to consider that the Standish Group is a commercial concern and that shielding their data and presenting it in a way that is advantageous for them can be expected.  We are not dealing with a not for profit research group subject to peer review.

Just for kicks I built the following chart by grouping all the “failed” and “challenged” together from all the CHAOS report information I could find on the web.  I’m assuming that the CHAOS report methodology has been constant over the years (was it?).  Even with a built in bias you see that both groups flat line over time.

 

My own definition of success is no more that 10% off on cost, no more that 10% off on duration, and no significant scope reduction.  By that definition, and based on my experience, I’d say that the same conclusion holds true; the success rate has flat lined over the years.  Whatever that success rate happens to be.  Why is that so?  Here is my personal CHAOS theory; no butterfly wings required:

• Requirements are fuzzy, often documented out of context and not tied to deliverables. See this previous post. If you don’t know what you are delivering how would you when and for how much?

• All requirements are deemed equal. No consideration is given to a must have/nice to have classification. If a particular requirement addresses a seldom encountered condition or action is it that important? I believe that the Pareto principle applies here and that 20% of requirements cause 80% of the cost. Why not implement only the true essential requirements; saving costs and complexity?

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkeIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.

Do we need accurate estimates?

You bet your life you do and you should involve as many people as possible developing one.  If you do get that accurate estimate you will enjoy, in no particular order, the following benefits:

• Focus on the deliverables; hopefully you started with a WBS. Are the task in the estimate directly related to the deliverables or are we gold plating?

• Buy-in from your team members and management. It is not YOUR estimate anymore, it is EVERYONE’s estimate.

• You can run a Monte Carlo simulation to figure out the realistic end date instead of the optimistic one. It is pretty amazing how both values may differ.

• You’ll have identified the training and staffing needs you’ll have if this project becomes part of your portfolio.

• A strong basis for contractual negotiations. Now your sales force knows how much you think this will cost and why.

• If the client says you are too high by X your sales people can ask what can be dropped from scope.

• If your company wants the project to satisfy both its Balanced Score Card financial and customer objectives we now know how many hours we may agree to give away to gain a new client or keep an old one. Remember; do not drop the rate, give hours away instead.

• Faster response time when revising your estimate following scope changes. You already have figures out where you can cut. If the client doesn’t volunteer potential areas of scope reduction you probably have identified them already.

• You’ll have a good starting point for the next time a similar project crops up.

Of course you’ll only know how accurate you were after you get the project and you deliver on it…

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkeIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.

Have you ever been architected? ...

... I have.  (Sung to the tune of Jimi Hendrix's 1967 track "Are you experienced?")

First let me say that this post does not intend to take shots and enterprise architects or business analysts; we are all in this together.  The aim is to comment on a possible cause for typical complaints with software projects: stakeholders do not get what they expected, when they expected it, and for the price agreed upon.  As a corollary, the software services provider does not make the expected profit.  No one is happy. 

Here is how the story unfolds:

• As the bidder, you get to estimate a project based on a Request For Proposal (RFP) package. This package contains all kinds of information about the client, the stakeholders, the bidding rules, and the requirements. Often the package is fairly vague about deliverables; this is the root cause of the problem.
• Whoever put the RFP together spent a lot of time discussing needs with stakeholders and extracting requirements from those needs. During this process a list of deliverables, think WBS, was discussed. Believe it or not, in some industries the WBS is included in the package, becomes the basis for a fixed cost bid, and later, for progress and financial reporting.
• Stakeholders would have legitimate expectations of having their needs met but they will be disappointed; the “What does done looks like?” question about deliverables was asked but the answer was not properly documented and the bidder is in the dark. The bid package has descended into the minutia of requirements disconnected from deliverables. This is equivalent to ordering a bunch of building supplies (the tasks/features/requirements) but expecting delivery of a bungalow (deliverables); how do the parts relate to the whole? What is the likelihood of satisfaction?
• In response to the RFP you come up with a cost estimate and tentative schedule. Because of the missing deliverables a time and material approach may be suggested even if a fixed cost was requested; this will likely be rejected but, if not, there is a high likelihood of recrimination later in the project.
• The bidder may be told that he is too expensive and/or that delivery is too late. A phased approach may be suggested to clarify the deliverables (time and material phase) and refine the schedule and cost estimate; this is also likely be rejected as it will appear to redo work already performed by the client.

There are ways to avoid or mitigate the problem and its impact:

• You get to engage with the client early on and work as a trusted advisor while the RFP is being created. This may mean that you are not allowed to bid to avoid an apparent conflict of interest.
• Strict gates are applied to prevent the project from moving forward without agreeing that what is being developed is what was envisioned.
• Both parties get ready for very strict scope control.

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkeIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.