When the client is wrong, everyone is wrong

I have experience working for both internal and external clients and all levels of them (from the bottle washer up to the cook). There have been many good relationships and some bad ones….but at all times I had the understanding – based on the age old saying – that the client is always right…but what happens when the client is wrong. Well, the way I see it is, if the client is wrong EVERYONE is wrong and everyone ends up paying for it in some way, refusal or inability to pay for services, reputation and self-esteem. When signing on to do a job we sign on to deliver a successful product, one that meets/exceeds the client’s needs and provides something positive for them. Some project managers see the delivery of what was asked in a timely/cost-effective manner as the only real measurement for them…how wrong they are. When you sign on for the job, you’re joining a team, you’re part of the group effort to make something positive happen and part of the blame if it doesn’t meet ALL of the client’s needs. Bottom line – in my opinion – if you don’t want to be part of the team don’t sign on, if you’re not at the level where you have ‘some skin in the game’ than there’s a good chance you’re not fully committed and that could be start of something bad.

Make your own something

Another great idea presented on FLOSS Weekly (http://twit.tv/floss92), MakeBot (http://makerbot.com/) – basically an open source 3d durable product printer. You create or use another’s design to print out the object in 3d, could be used to actually make something useful (scissors were mentioned on the show as something to be worked on). Imagine the ability to make simple replacement products, used by car repair shops, home hobbyist, designers, toy makers, etc. Potentially reducing the need and reducing the cost of making simple things overseas…and it’s under $1,000 TODAY! Imagine in a few years what this could mean? Perhaps a device that will bring creativity back to the US shores….however you look at it, its one of the more interesting Open Source initiatives around (beats another CMS).

How Google Wave – hello touchy feely, goodbye fire-and-forget

I’m a firm believer that an effective project manager (PM) needs to be an effective communicator. A PM cannot hope to positively impact a project without being able to successfully communicate with the team (including sponsors and users) and to get the team to openly/honestly communicate with each other. There are many stumbling blocks to effective communication, including:

• Conflicting interests
• Common terminology and understanding
• Differing personalities

One of the causes of the above stumbling blocks is proximity – people are people and people tend to form into temporal tribes whenever possible (cliques for a better term). When people ‘tribe up’ they tend to form their own interests, terminology and tribe personalities…each adding to barriers of effective communication…so, why am I saying that Google Wave is the start of something good? Simple, its primary function is to allow individuals to group contribute to ideas (Wave’s) and the ability to easily add in people from any ‘tribe’ to review how the conversation progressed (replay)…the base assumption here is that the PM would open the idea to anyone/everyone with any related interest. This allows for the crossing of traditional IT boundaries: programmers, sponsors, testers, end users can get included directly or indirectly (polls for example) into an on-going discussion. The crossing of the boundaries starts to reduce the barriers and helps personalize each individual’s concerns, interests and understandings. NOW – Google Wave in itself will not help, no tool really helps – tools enhance, the PM and management need to enforce/reinforce the need to openly/honestly communicate and to include/invite ALL people with interests into a conversation – Google Wave allows for this conversation to take place over time and distance…and allows for the reaching out to larger groups through polls…it’s not a fire-and-forget approach of email, its and ongoing live discussion with the ability to incorporate polls, documents, pictures/mockups, etc….

Done

Just browsing through Yahoo Group’s eXtreme Programming forum  and came across a discussion on what Done is and when you have Ron Jefferies and Kent Beck contributing on the discussion you can’t help but gain or be amused. Kent Beck’s definition is ‘requires no further investment to get the return I anticipated’ – simple, defined, open, accurate. Done is done as determined by the person making the decision. You can try to definitively describe what your anticipated return is through TDD, predefined plans, requirements, automated burn charts, PMO’s, etc…but it takes the decision maker, at the time she/he designates to determine Done…Done could be a sign of success, realization of failure or acceptance of good enough. Books, classes, endless blogging (this one included) can try to better define done…but Mr. Beck, Master of his domain, has defined it best…

I now know how to prevent most project failures – thank you Capers Jones!

The secrets are out, the underlying reason why projects fail, some so badly that they result in litigation cases. The glove fits, the DNA was matched, the evidence is overwhelming AND the amazing part is that this is well known and communicated information. Let me start by saying that I had the privilege of attending a conference that Capers Jones presented at, one of the most amazing moments was when he told all of the CIO’s present (from some very large companies) that they are making the same mistakes that have been made for 20+ years and are directly responsible for them…since the cause/effect and method of correction has been known and identified long ago…and the room fell silent.

Here’s a link to the entire paper that will cure the curse of project failure:
http://www.itmpi.org/assets/base/images/itmpi/privaterooms/capersjones/Defenses2008.pdf

in Summary:

• Estimating – either poorly done or rejected. Just amazing how knowledgeable business execs/owners can turn a blind eye to hard data AND then question why the project failed.
• Change Requirements – the typical case of the scope continuing to grow without control and without taking the impact to time/costs into account. I think metal stress was a known test in the 1800’s…200 years later and IT/Business hasn’t found the book.
• Quality – as stated in the doc: defect prevention, defect removal and defect measuring – abc’s of QA.
• Project Tracking – as stated in the doc: Achieving specific and tangible milestones; 2) Expending resources and funds within specific budgeted amounts.

WAIT A MINUTE!! It can’t be that simple!?! These are known and easily implemented changes!?! Short Answer: Yes!

Well next time a project fails don’t go looking for Godzilla tracks, just dig Capers Jones article back up and bang your head against the wall.

The tracks are down, now deliver the goods

It might be the changes I’ve seen in the last 25 years, but where I’m standing now software development is more about implementing than discovering. Gone are the days of trying to build solid development approaches, computer connectivity, easy system setup, quality tools, mass data storage, etc. Work is still being done in those areas, but the foundation is well in place and understood. Just think about how long it takes to set up a simple website? And what technical ability is required…I would say 10-15 minutes and minimal skill…example Square Space (http://www.squarespace.com/).

Do we need to start modifying our approaches, standards and life cycles to meet the implementation phase? Going from a track laying to goods delivery type of thinking? Simple answer is Yes! More emphasis needs to be placed on short term business benefit, time to market and quality messaging….put those work boots away and put the pick back in the shed.

(image from: http://whitemtncentralrr.editme.com/RailroadHistory)

Tracking is not the same as doing

There seems to be some level of buzz over FitBit (http://www.fitbit.com/), a device that tracks the calories that you’re burning as well as how much you sleep. The base idea is to let you know how your exercise regiment is doing as well as how well you are resting…but not the number of calories you consume. I have to admit that I’m slightly an exercise freak (working out 5 days a week) and at times have become obsessive, given that, I find no real value in this product (but best of luck to them). The first thought that came to my mind was that it will give people the false impression that they are actually doing more by just wearing the device – letting them know how many calories they are burning and perhaps justifying that extra spoon of sugar in their coffee…which bring us to the project management discussion of the day – Tracking is not the same as doing……..

I’ve been in a few companies where the CIO’s action to improve IT is the implementation of a PMO or more stringent project management. All well and good, since in order to determine what the root cause issues are and to know if you are improving over time the first thing you need to do is measure where you currently are…HOWEVER, in many cases the implementation of the tracking (PMO or other) is it, no further changes, just using the collected data to show people that work is being done. Well, guess what, the difference in productivity between the day before the PMO was implemented and the day after is the same - there is a theory that there is some short term improvement to productivity by just measuring it – something about giving the workers either a feeling or importance or fear to help them improve – short term only….Same idea as the FitBit, measure all you want, but the most important thing is to improve.

• don’t lose the goal of improvement and 
• don’t let fancy charts and interesting numbers get in your way
• don’t feel good about where you are
• don’t feel you deserve something just because the reports look good
• always be on the lookout for way to improve 
• make sure your primary focus is on people – the key to any real improvement