16 December 2010

Quality Work v/s Business Value

I love Laura Brandenburg's blog Bridging the Gap. If you're not a follower of it, get over there now as she and her fellow bloggers delivery quality every single time. One of her recent articles tackled the subject of how to win the respect of your project teammates. Here's a snip-it...
The most direct route to earning respect from your project teams is delivering high quality work. It’s really as simple and as difficult as that.
Laura and I had an exchange in the comments section, not in any way bad, just a bit of a difference in how we phrase things. I feel as if I did a rather poor job of explaining myself there, and thought the topic was one of importance, so I decided to bring the conversation over here and see what the Better Projects readers thought about the question.

To me, high quality work is not the way to gain respect. To me, respect is gained by providing value. This applies not only to your team mates but also to your stakeholders. I can produce an extremely high quality piece of work about the process cats use to mark their territory. It can include requirements for leaving faceprints on walls, process flows for the best rubbing spots and lots of rules (which cats disregard) about when not to annoy the one who feeds them.

However, if I delivered that document to a project team installing a new CRM system, you're not going to endear yourself to the team. Yes, they'll probably see what a quality piece of work it was, it simply wasn't relevant to the subject at hand. You'll probably be accused of wasting company time and at the best, receive a stern talking to from your boss.

Yes, that's an absurd scenario, but I use it to illustrate the point... high quality doesn't necessarily mean it adds value. The same goes for our stakeholders viewpoint on our deliverables as well. If we deliver a system with zero defects, is under budget and early, yet it completely fails to add value to their business, then who cares how flawlessly we ran the project?

In the end, I do think Laura was meaning what I've just said, I just see it in different terms. If you assume that two documents provide equal value to the team, with one being a higher quality of work than the other, give me the high quality job every time.


  1. I agree with you, but I also think there is more to it than that. Respect is very multi-faceted, and requires much more than one end result. For example: say you are brilliant, and consistently produce high quality deliverables, but treat others poorly in doing so, or fail to show others respect. You may be respected for your work, but I don't think you will have truly earned the respect of your colleagues.

  2. There is no doubt that it all boils down to delivering right value to all your stakeholders. But in reality there are instances when definition of real value in itself gets subjective and becomes relative to the end result. Meaning deciding value was delivered or not just considering the end result (success or failure) would not be fair. As a leader you should be able to highlight and prove that all required efforts were put by the team, were moving in the right direction as per the specific situation and team had the right focus as well. It was just an uncontrollable situation (change in external environment, business condition, changed priority, lack of insight by any of the external stakeholder which is not controllable beyond an extent etc.) that changed the equation and meaning of true value finally delivered. If this can be done even to the internal stake holders within the organization, IMHO is enough for one to earn the respect from his team members.
    Only pre-requisite here is the arguments provided have to be based on factual data, be realistic and in right context.

  3. Hi Ted, Thanks for the positive feedback and taking time to elaborate on your perspective. I agree with all of your points above and still think we are using different terms to talk about the same concepts.

    You write:
    "However, if I delivered that document to a project team installing a new CRM system, you're not going to endear yourself to the team. Yes, they'll probably see what a quality piece of work it was, it simply wasn't relevant to the subject at hand. You'll probably be accused of wasting company time and at the best, receive a stern talking to from your boss."

    I would not see this document as a high quality piece of work if it's not relevant to the team and useful to the project. I think this is one of the core issues facing the BA profession -- a tendency at times focus on documentation as the end-all, be-all of our roles. Documentation has weight and can feel like a solid accomplishment, but in my opinion, if it's not useful or represents requirements that are not well understood by the team, it is not the output of high quality work. It does not meet expectations.

    We just can't let ourselves fall into the trap of assuming that "high quality" deliverables that meet some intrinsic standard of quality requirements documents represent high quality business analysis work. That's a recipe for professional disaster.

  4. I think the trick in in the adjective "High".

    High is not the same as appropriate. Finding the right level of quality is often not as easy as it might seem.

    When you are new you don't really know what good enough looks like.

    When you are in the middle of a job you can often get struck on pushing it just a little further to satisfy your own standards.

    When you work for a vendor or consulting agency you have more than the individual job you need to look at. You need to consider the brand. In three years time when someone looks at your work they'll be judging the quality of the business by the quality of this piece of work.

    It gets quite complicated.

    I think we all agree on the bottom line; quality standards need to be negotiated and agreed per job.

  5. Well, I think we can all agree that poor quality work is totally unacceptable.... OK, OK, the quality question.

    I produce very few deliverables used just by myself; the key to quality is if what you deliver can be used by the person/group accepting it to do their work successfully.

    Most deliverables are intermediate; only the final one really counts, like a system being used by people to get their own work done. But, we need to take steps to get there, and things get passed from step to step. If your deliverable causes this progress to falter or stop completely, what you produced is poor quality, simple as that.

  6. Sorry, not been ignoring this, but being diagnosed with pneumonia has kept me down for a couple days. On the mend now, so no worries.

    @Laura Requirements doc was nothing more than an example; substitute a workshop, validation and verification or any other BA task and the same point remains. I see 'quality' as only a single input to 'value'; others being timeliness, correctness, completeness, etc. I agree though that we're driving toward the same goal, just feel 'value' is a better way to describe that goal.

    @Craig & @David completely agree that what is quality can change from project to project. there are a few teams i've been on where i had to only turn in a vague guideline document and the resulting output from the development group was dead on. others i've had to nearly code it myself to get it right, despite numerous defects, mockups, simulations, etc.