Eloquence is eloquent

What eloquent design? A design that takes the place, time, people into consideration as well as providing a high quality and practical delivery. Most IT projects are not eloquent. Why? Lack of skill, sweet and simple. We (IT people) tend to focus on function and delivering what’s requested, not what is required and not in a way that anyone would look at and even imagine any form of eloquence. Lack of vision, lack of courage and lack of pride lead us down the road to delivering one road house after another instead of a Frank Lloyd Wright masterpiece. Should we strive for better? We better start or the constant low quality, narrow focused delivery will continue to feed decisions makes with the confirmation to the idea that IT is no more important and no more critical to business success than the maintenance crew (no offense to the maintenance crew).

The feeling isn't fear, it's just telling you to move

Dogs bark, babies cry, projects hit bumps and project managers need to act (not react).
The time and effort that you put into the Risk Management plan comes into play when 'things' start to happen.  Don't fear problems, they'll happen, fear the lack of planning...

What You Want To See Is What You Get (WYWTSIWYG)

Be it from friends, co-workers, Reports, Audits, Outside consultants, Inter-Galactic Gurus, expensive Standish Reports, inexpensive internet discussions....where ever you get your information from, chances are it's going to leave you with the guidance or direction you initially envisioned.  Could it be that you're SO SMART and INTUITIVE that you knew what all the experts would have said?  Most likely not...chances are that the information you're seeking, the advice you seek and the meta-physical data gathering done is very tainted by what you wanted it to be...in other words, YOU MADE THE RESULTS say what you wanted it to be.

In psychology, there's a double blind technique used when gathering data - the basic idea is removing the originator of the data request from the data points (the patients or test victims).  This often results in a much more realistic answer to your base question (make sure you're asking the question correctly...otherwise you'll be doing MANY of these data gathering exercises).  Is this a valid way for a IT manager to gather this kind of information? Why not? Why not send your staff out with a question like 'Is Open Source the way to go to be more productive' (as opposed to: I need to stay employable, I know Open Source is big, get me info to bring it into this job so I can learn for my next).  Are there alternatives to the double blind approach? If you're really interested in real, untainted information (sometimes you may not be for many reasons) - look for information that goes against what you want, question ALL information that confirms what you want...ask someone with an opposing view to provide the information.

The results you find are usually the results you seek, at least on paper.

What we got here is a failure to communicate

Communication comes in many forms....some more direct than others.What people say (meetings, emails, etc.) is often not what they want to communicate, but often just a gentle, comforting bandage for what has happened OR about to happen.  The old 'we reward team work' talk followed by decisions to have the team work physically apart or rewarding individuals is a good example of this.  What is being communicated is that they value specific people within the group, for whatever reason, and want those around 'the chosen' to follow and do as needed to support them (not really team work is it?).

I often hear people complain that MANAGEMENT doesn't listen or understand...well, management is in the same boat as everyone else and the ones that make it to that level understand (either through skill, attrition or luck) what is expected of them and react accordingly.  When management say's 'Quality is essential' and then reduces the QA group...what they are really saying is 'you programmers better start coding better, because our costs are to high and your output to weak'.......not 'we plan on putting more $ into the group to ensure quality'.

Don't get frustrated and discouraged, open your eyes, understand what is really being communicated and either accept it or not.........

Dr. StrangePM or: How I Learned to Stop Worrying and Love the Outsource

A mad project manager embraces outsourcing and the corporate politicians lose control. Sounds like some bad, made for SyFy Channel movie, but it’s true. The day I started to embrace outsourcing is the day the corporate ‘outsource’ hammer lost it’s affect. No longer can I be threatened with lose of job, status and ego. No longer am I complaining about communication problems, late work or poor quality. No longer am I making the almighty dollar that corrupted my original desire to enter software development.

Consume or be consumed, I decided to consume and become part of the solution. The ever present top management needs to reduce costs and disregard the ‘man in the trench’ screams of oppression is the noise of yesterday. Today, I’m on board with outsourcing. The cost savings aren’t that great, the quality isn’t that bad and overall I think we’re still as productive as we were 20 years ago – for better or worse.

I feel relieved of the pressure to keep my programming skills ‘up to speed’ and have stopped worrying about the latest code standards. The box has become black and I’m stacking them up like Lego blocks. The promise of ‘object oriented’ programming has been transformed to replicable off-shore teams.
Do I miss getting my hands on the code? No, I actually still keep them in, but focus on the data, where the value has always been. Do I miss the nights of wrestling with thousands of lines of undocumented code that’s doing what it was written to do, but not what the client wanted? No……

I don’t think the top management desire to cut costs has been achieved, but I do think outsourcing has helped American developers from the never ending code wrestling matches and instead moved us to the bigger ideas and issues at hand.

It’s not my problem

One of the major challenges of a project manager, or any manager, is determining is who owns the PROBLEM. By default, the PROBLEM is owned by the person with the biggest guilt complex (aka ME)…and not the person who can actually address the PROBLEM. No matter how hard the current PROBLEM owner tries to get others to help resolve the issue, the PROBLEM tends to bounce right back, as if it was attached like a paddleball. The end result: the PROBLEM is not effectively addressed and blame and future problems have a greater tendency to be associated with ME.

Ok, rant over, now some definitions:

• The PROBLEM – anything that went wrong
• ME – the Person who always seems to be working through the teams problems

Without trying to over-define everything, let’s just say that the PROBLEM is something that needs to be corrected, is understood enough to know who it should be assigned to and is of a severity enough that it needs to take priority. Any additional information is…well…nice to know.

An effective process would be:

• Centralizing problem reporting – an excel sheet to some sophisticated bug tracker
• Problem Triage – someone (ME) needs to determine how severe the issue is and WHO the PERSON is that is most associated with it and can resolve it
• Assign (you need authority) to the PERSON
• Follow up and make sure the problem gets attention and resolved

Seems simple, but if you ASSume people understand the process and will voluntarily follow it…well let’s just not ASSume, let’s communicate to the team and to management and let us ASSume that we have the authority to push the PROBLEM to the right PERSON….as difficult as assigning to the right person is, the actual resolution is based on the PERSON’s focus and attention to the PROBLEM. The easiest way I’ve found for this to happen is to send out a daily/weekly report of all active PROBLEMS, who they are assigned to and HOW LONG they’ve been out

standing. Peer pressure and Management pressure can then take it’s course.

Interpersonal communication

Communication, (1) it happens, (2) you can't time travel to change what was done, (3) it isn’t easy and (4) you need to take everything going on into consideration…basically the four principals of interpersonal communication…….let’s discuss It Happens……

We’re always communicating – all of the time. Don’t even consider hiding from anyone, that’s communicating in itself and most likely a message that you did not want to communicate (or perhaps one that you did – but it’s not one you have real control over since you’re not guiding it……right?).

We need to realize that our communication flow is always on, we need to either take ownership of it or let it run wild: our choice, either way we’re responsible for the outcome. Like a mighty river, it can’t be stopped and at best only controlled for a temporary period of time. Let’s take our interpersonal communication lifecycle under s microscope and examine the major stages:

Pre- relationship communication – this is the communication that occurs prior to establishing a firm relationship with another person. From the moment you bump into them to you have a better understanding of each other. A good example is the sending of your resume up to the end of the first interview, how much does the recipient really know of you? And what do you think decides their understanding of you at this stage?

• Your name
• Your writing style
• Your background – shared experiences, similar education…
• What’s on their mind, what have they gone through getting to work, the coffee that just spilled on their desk
• The format of your letter/resume – can they easily read it? Does the butterfly image in the upper right hand corner amuse them? Or distract them?

When communicating to an unknown person, there’s little you can do to control the above ‘feelings’, but the little can go a long way:

• Keep it simple and keep it direct. 
• Don’t assume anything about shared experiences or common terminology. 
• Don’t overwhelm and don’t underwhelm. 
• Make sure you tell the story the way you want the common reader to understand it.

(to be continued)