Lessons Learned

Just Because You Can Doesn't Mean You Should

Do you struggle with this too?

It can take different forms:

  • ‘Doing it yourself’ when it would be better to let someone else handle it.
  • Gold plating, which is adding more features because you think they are ‘cool’.
  • Putting extra effort towards something other than your product without any potential value to the customer.

And more..  Heck, I’ve caught myself doing a few of these just recently. The other day I received an email from a new student of my online project management training. There were warning messages showing up all over the place, and she never received her login details after purchasing access to the course.

I jumped in right away and fixed it as soon as I could. It turns out my web host had upgraded their versions of PHP and mySQL, and the software I purchased to deliver the training was using some old, deprecated PHP functions.

But as I was sitting there debugging the code a question crossed my mind.

Why am I doing this?

Doing It Yourself

I resolved the issue. I can debug php code on my own server. But should I be?

Should I even be hosting this on my own server where I’m responsible for all of the configuration, design, etc?

Would this problem have happened in the first place if I didn’t insist on ‘doing it myself’ and let a team of people who are really good at avoiding problems in the first place do it?

The answer is no, it wouldn’t have happened. My students would receive a better experience and I could have spent more time developing new training material or writing to help more people, instead of debugging code.

So I’m looking into migrating my training courses to a new platform, hosted by a company who knows what they are doing.

I just freed up a few hours per week of my time to do more teaching and writing. Sweet!

Gold Plating

Sometimes as developers we think we know what the customer wants better than they do.

It’s true that sometimes they don’t know what they want until they see it. There have been several occasions in my career where I had my teams develop prototypes ‘on the down-low’ to show to a customer because we knew they’d love it when they saw it, and authorize us to proceed. And most of the time, we were right.

But gold plating occurs when you go further and fully develop new features in a product without the requisite assessment of need/value from the customer and without accounting for the additional work in your schedule and budget.

And yes, I’m guilty of this too. There are several aspects of my online training that I spent considerable time on that no one uses. If they were scaled-down features to be used for experimentation to gauge student interest that I could enhance later if the need was justified, excellent. That’s iterative development, and is wonderful. But I spent a long time on some of these features that are now happily hosting a family of pet dust bunnies.

Fluff

New project managers fall into this trap all the time with documentation. I know I did.

You spend tons of time on a project management plan because you want to make sure an auditor who might review your work would say “You get a gold star for making it look important, especially with all the flowery language and the fact that it’s 300 pages.”

Yea! You can knock someone down by throwing your plan at them.

Here are the lessons I’ve learned and want to convey to you about documentation:

  1. Identify the ‘customer’ of your documentation clearly
  2. Every word must add value to the people you identified in # 1
  3. The shorter and more concise, the better. The people in # 1 might actually read it.

If you can play bull$#!t bingo as you read through your documentation, try again.

Better yet, put your bull$#!t detector hat on as you are writing it in the first place.

Just because you can doesn’t mean you should.

What are your examples of doing something you shouldn’t have?  

Come on, it’s very therapeutic.

It’s easy, just start with something like “Hello, my name is Josh. And I’m a gold-plater.”

{ 4 comments }

Top Ten Reasons Why Projects Fail

Thumbnail image for Top Ten Reasons Why Projects Fail by Josh November 30, 2011 Lessons Learned

Guest post by Dr. Ian Clarkson Why do projects fail? Problems can manifest from anywhere on a project but there are several elements of a project that if managed poorly could mean that the project may fail to deliver: Poor sponsorship If the people at the top are not supportive this will severely hamper or even [...]

Click to continue…

Lessons Learned in Project Management

Thumbnail image for Lessons Learned in Project Management by Josh June 24, 2011 Career

I have learned sooooo much over the past decade that I’ve been managing projects. So when Terrell asked for sharing lessons learned, I was all over it. My blog and project management training pretty much are my lessons learned from over the years.  The great thing about having written this blog for 5 years now [...]

Click to continue…

How Cutting Corners Costs You More

Thumbnail image for How Cutting Corners Costs You More by Josh March 9, 2011 Grab Bag

It happens to all of us. You’re a developer or a project manager and here comes the customer or stakeholders asking about how to cut a few corners. Your spider-sense should be tingling, because usually this will cause you more pain than it’s worth. Get the Full Perspective In order to make a decision like [...]

Click to continue…

Good Project Management is Common Sense

Thumbnail image for Good Project Management is Common Sense by Josh February 26, 2011 Definitions

Project management is one of those things that seems very complex when you’re starting out. But after you been doing it for a while, it really turns out to be a good dose of common sense with some science and discipline added in. I think many project managers tend to focus on tools and techniques [...]

Click to continue…

Project Failure: We are at it Again

Thumbnail image for Project Failure: We are at it Again by Josh December 4, 2010 Lessons Learned

Serendipity happens. I responded to a student Inside pmStudent e-Learning with what turned out to essentially be an article about criteria for project success and failure. A few days later, Shim wrote “Projects failure rate – the conventional wisdom is wrong!” on his fantastic blog.  I started leaving a comment, and it became one of [...]

Click to continue…