This about this:

If you have a project with an estimated cost of $1MM and you expect a return of $1.1MM then strict governance and process controls are critical to success. A variance of 10% will take you from profitability to a loss.

If you have a project with the same estimated $1MM cost but an expected return of $50MM then project management is less critical. a 10% variance will not really matter in the big picture. Given my fictional example even a 100% to 500% cost overrun could happen and keep the “success” label.

So the take home message is that project management is critical for useless projects. If you have a great project then even with terrible project management you will still be successful.

In my own experience we run a might tighter governance on the weekly ‘Features and Maintenance’ sprint team as opposed to the month long ‘bigger feature’ sprint.

So put your bad PMs on key initiatives and shuffle the best to the menial tasks.

And get yourself on a ‘no-fail’ path by ensuring that all your projects have large ROI with logarithmic (hockey stick) growth.

I love reading articles by fearless people with ‘tenure’ at IEEE!

http://www2.computer.org/portal/web/computingnow/0709/whatsnew/software-r

I’ve mentioned the book Adrenaline Junkies in a previous post and I’m not seeing the value in a common language for discussing problems.

Today’s pattern is the ‘Onion of Stupidity’.  This is a common pattern where you build up hack upon workaround upon compromise, inject a little shortsightedness and wind up seeing a good chunk of your effort goes into cleaning it up.  A colleague here promoted the term “technical debt” to describe issues were we these types of issues and help us prioritize them.  I’m thinking that my Onion is more about ‘strategy debt’.  The onion is usually built with best intentions at all sides.

Peeling back the layers of stupidity is tedious and takes time, but cutting through it makes everyone in the room cry.

I’m sure we have all been here.  I had 2 instances of it today at work, and one with an old friend.  He wanted me to update some joomla modules and I said yes.  I go to ssh and wget the files and find out there is no ssh.  Without that I have to download the files, extract then and upload lots of little ones.  Then I find that some of the original files are edited so the have to be diffed.  Now I have to download the files and diff them.  Then I want to check but can’t run it without the database.  I just restored my local ubuntu image and don’t yet have MySQL. So I go to install MySQL and don’t have connectivity yet between the VirtualBox and osx….

So the first layer of this Onion that I must peel is to fix Bridged Ethernet.  Or I cut the darn thing and move the site to a real hosting company.

So while I’m pretty much out of luck on my personal life here at my day job we all got together with a commitment to peel back our layers of issues as a team and focus on building out a solid foundation.  Hopefully the only onions we will have are the ones served on the sliders upstairs…..

I found an interesting article today.

A House With No Front Door

It is written by a product marketing professional lamenting about dealing with ‘resource constrained’ engineering teams.

Seeing as how I come from a resource constrained engineering team I thought it was an interesting read.  The premise of the article was the disconnect as described:

Perhaps it is my job to get this perspective across to them, and I try to do that, but the gulf between the “feature triage” perspective that many engineers have, and the “holistic” customer or market perspective that is needed is enormous.

So the article goes on to talk about how engineers struggle for workarounds and laments

If something is truly necessary, then why is it not worth implementing correctly? Yes, I understand deadlines and resource constraints and marketing, sales and competitive pressures etc, but it is very easy to fall into the habit of providing partial solutions to problems, and laying the burden of what’s missing onto users.

And the final closing argument revolved around the house this persons team would build

Imagine if houses were built with this premise, and every time some aspect of the house was discussed, questions about workarounds were raised. You’d end up with a two storey house, that required external ladders to get to the second floor, a fireman’s pole to quickly get down to the first (no wasted floor space inside because of unnecessary staircases), that wouldn’t have a front door (the back door should be sufficient), that had only one big bedroom and closet for everyone (those extra walls and doors cost time and money you know), one bathroom (it would be an outhouse to give equal access from either floor), and only a wood burning stove to both heat the house and to use for cooking (minimizes unnecessary duct work).

The crazy house happens because developers know that they can’t give the people what is being ordered, but they do their best to get a roof over their customers heads.  The real question is why did product marketing order a two story house when they could only afford a ranch?.  This would not happen in a house because the builder would simply raise the up front costs.  The recent sub-prime lending issues clearly show how people are willing to pay more then they can afford in order to get what they think they need.  So people that should be in a small ranch wind up being in a 3 story colonial until they go into foreclosure.

In a business if the developers do what builders did and simply raise the prices and give people what they ask for, then they would go into foreclosure as well.

Perhaps the real question we should be asking is why do product marketing people continually try to ‘give the customers what they want’ without getting the resources and money in place to achieve their goal.

I’ve been writing software against requirements for over 20 years and have seen this over and over when the product people and business people are not the same human or at least in-sync.

Scrum and Agile are desinged to solve this by making it a team effort.  So in Scrum it is not the ‘developers’ that build this Dr Seuss house, but the team.  I think this is why many people fear Scrum. There is no ‘justifiable failure’.