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)

Grady Booch

If you've never heard of Grady Booch...well, there's a good chance you wouldn't be here......like DeMarco, Yourdon, List and all the other greats - Grady is a Master level, old school, IT genius.....for a more definitive background, check wikipedia (where else would you go): http://en.wikipedia.org/wiki/Grady_Booch

I just happened to come across his podcast, the reason for this post - a must listen for all you real IT people out there: http://www.computer.org/portal/web/computingnow/onarchitecture?utm_source=bronto&utm_medium=email&utm_term=examines+the+triage+process&utm_content=meade.rubenstein%40yahoo.com&utm_campaign=CN+November+17%2C+2010

Also found on iTunes Podcasts......of course

Time Zones

The risks and complexities of Project Management evolve around communication. How do we effectively communicate needs, updates, feedback, priorities, expectations, etc. A new twist to this, really not that new – but one that I’m currently appreciating more, is the way the world works, specifically time zones. Talking across time zones includes talking across cultures……in addition to being on a call before you wake up talking to someone who’s ready to go home, think of all the common understandings that don’t exist. I recently had a review of some quiz functionality being set up, one of the questions was about vegetables….it took a few minutes to realize the foreign word entered was a local, well known, vegetable. If you can’t both understand what the local potato is, what makes you think you can understand anything more complex? On the positive side, I got a quick intro to some local Indian blue looking, squash looking, potato something that is apparently feeding a good portion of the world’s population.

‎"A champion is someone who gets up when he can't." - Jack Dempsey

Maybe, just maybe, project managers need to think of themselves as trainers and corner men (women) for the teams we are working with and the projects we are responsible for. There’s a certain rhythm in the preparation, fight-night and post fight that takes place for all professional fighters. There’s also a certain progression of ability for boxers and supporting staff, all based on prior success – success easily being defined in boxing as the last one standing.

Prior to any boxing event there’s around 12 weeks of intense training and preparation – aka boxing camp. The boxer starts ramping to top condition, the trainer and supporting staff get into the boxer’s skin, understanding abilities, gaps, trigger points, specific needs, etc. The training is the true determinate in the boxer’s ability to win, by the time the boxer enters the ring, he is just executing – utilizing his physical and mental conditioning and skill training from the prior 12 weeks. There’s always a chance for a stray/lucky punch from either side – but those are rare, the outcome is determined by the base ability and the recent training. How much training does a project manager and team have prior to a new project? Typically not much and maybe this is the one area that we need to focus on – REALLY focus on. After all, it’s all about the people – projects don’t get themselves done – right? Maybe we need to go through a few weeks of getting to know each other, setting up communication protocols, processes, tools, etc. before the next major project begins. These activities usually occur during the first few weeks of the project, causing strain, confusion and later on-rework. Sounds like a Boxer’s approach to PM is a good buzz sound bite…anyone up to writing a book?

10 Commandments of Project Management

ONE: You shall have no other goals but Business Success

TWO: You shall not make for yourself anything that is already made and working, not process, not group, not support groups, not teams

THREE: You shall not take the name of the Business in vain, you are the Business and need to represent it well to all

FOUR: Remember to rest and relax and enjoy life

FIVE: Honor your family and your boss

SIX: You shall not indiscriminately fire employees or stop work

SEVEN: You shall not steal resources from other groups

EIGHT: You shall not harm other Business units or Partners

NINE: You shall not falsely report either to enhance yourself or take away from others

TEN: You shall not covet another team you shall not covet another teams clients, nor their team members nor their tools, nor their projects, not anything that belongs to another team

In practice there is

In theory there is no difference between theory and practice. In practice there is.
Yogi Berra

If everything being taught about project management was practical and applicable than why are there still so many failed projects? Simple, because there is a difference between theory and practice and that's the one of the major missing lessons. A good project manager adjusts, effectively communicates and always reevaluates. Take your classes, read your books, think your deep thoughts and then bury them inside as you, with an open and honest mind, take in all that is happening around you. PMBOK, Agile, Scrum, Earned Value are all nice buzz words, your real value is being able to apply and adopt that knowledge to improve the situation that you are currently in.

Doing the right thing, right

Everyone is different, but we are mostly the same. I've worked in many companies and on many projects and have always felt 'different' when working with a team and on a project that I felt added to peoples benefit rather that focused solely on profit or getting widgets made. I'm sure there's many of you out there that feel the same way. It's nice making the big money and getting some of the spot light for performing above and beyond, but there is something special about doing the right thing and doing it right. I'm not looking for a pat on the back, but wanted to pat you - yes you – on the back for focusing on those higher goal'd projects...or attempting to. Share a project that you're proud of being part of....mine, currently a Health/Nutrition site......nothing like helping people get healthy.

Broken Windows

If you have not heard or recently read the Broken Window theory, I would highly recommend it. Basically, you should not complain about the base behavior you are seeing if it's the behavior that you have communicated, through your own behavior. What you should do is understand what you are witnessing and address the root cause. For example, if you accept misspellings in requirements, don't be surprised if your web site is full of misspelled words (one of my major flaws)........always set the quality standards high, the productivity and cost effectiveness will out weigh the upfront effort put in.

http://en.wikipedia.org/wiki/Broken_windows_theory

Act as if there is some value to the project...

To take from a much higher meaning message: we need to act as if there is some value to the project and find out that it doesn't than to act as if it doesn't have value and then later find out that it does. Sometimes (to often), project managers are not privy to all the information during the project selection/prioritization process takes place...we need to assume that those that are, are making the correct decisions and based on that, pursue the successful completion of the project as we would another project that we see as having clear value. Easy to say, but often difficult to stay motivated. The focus, in these situations, should be on performing out roles as best as possible, and trusting others...and learning, or trying to learn, there is a lot to learn in becoming a team player.

Back to the Bascis

When in doubt, go back to the basics. There have been no major improvements in Project Management since the building of the pyramids....plan, execute and track – fancier charts, nifty tools, amazingly obscure buzz words, but the basics have not changed for thousands of years. So, why do projects fail – the same reasons they always have and always will – not understanding or not following the basics. Focus to much on the tracking tools, assume people understand what they're suppose to do, close your eyes to what reality is and don't communicate effectively to Sr. Management and you're sure to follow the same path thousands of other project managers have followed – failure. Repeat after me:

• Plan
• Execute
• Track
• COMMUNICATE
• THINK

Drop and give me 50 pushups now...........

Go towards the light

There’s enough to do (for most project managers) just keeping existing projects on track and moving, the additional burden of ongoing process improvement is more often than not pushed to the side since many consider it a nice-to-have/low-priority effort. I think this is one of the biggest failings a project manager falls into. We (PM’s) are paid to reduce risk and as a result provide for a higher probability of success – right? If you believe in that, than our primary function should be process improvement even at the risk of the current project. Think about it, a failed project today in an effort to ensure dozens of successful projects going forward as compared to pushing a failing project through and then tackling the next project about to move into failure status soon after. We need to continue to move towards improvement, move towards the light at the end of the tunnel to ensure that when we leave, we leave a better environment then when we started. Step back, take a breath and look at the big picture.

It’s about forgiveness

Projects come and go, many are soon forgotten and some stay in people’s memories for a long, long time…usually the more painful ones, the ones that ruin careers, ruin friendships, marriages, dreams. Some people have problems moving on and often hold life-long grudges against those they think were the main culprit for those evil projects. Fortunately for me all of my projects have been very successful (just kidding).

I think we all owe ourselves and our current and/or former team mates a once a year complete clear the painful history, put the smile back on our faces, lift a beer in celebration of the attempt forgiveness day and I think its most appropriate around the Holiday Season (Merry Christmas and Happy Hanukah and Happy Kwanza and all the other year end holidays)…learn ye lessons from the past, but let the painful memories that stunt our growth and happiness be forgiven and forgotten.

(image from http://blogs.phoenixnewtimes.com/uponsun/2008/12/curtains_a_christmas_carol_at.php)

The greatest obstacle to overcome – desire

I’ve been in different companies and in different positions and the one common theme throughout all is the outright avoidance for the #1 obstacle to change – desire. A company might be doing great or it might be on the way to nothingness, the people could be top notch or very mediocre, the work environment ranging from open and happy to slave-like and demeaning…processes non-existent to CMA Level 5 – there seems to be no common theme in what makes the people in the decision making position have the internal desire required for real improvement. Desire is the one base element needed for change, change is a very uneven, scary place to be, one that many people avoid at all cost…but for those with the desire, one that could provide the greatest benefits – but sometimes not.

The biggest push back often heard is that the company is doing great, or at least good enough, stay with the known and continue to gain rewards. That’s the old wait and see the train coming at you syndrome.

Another is the knowledge that a bad or poorly executed change could cost the person their job…this is actually the same as above – wait and see the train coming. If you’re not gaining and you’re treading water safely why swim? Sharks! Currents! Endurance! Sooner or later someone comes knocking at the door looking for big results.

The downside to being a project manager is that you often don’t have the decision making position and at best have a strong influence on the person/people that do. There’s no process to add desire, you can’t provide a drink for it (even though a few beers at the right time could help) and you can’t influence it beyond where the decisions makers want to go.

Solution:
Serenity Prayer:
God grant me the Serenity to accept the things I Cannot change;
Courage to change the things I can
And Wisdom to know the difference;

Why Quality Assurance ain’t

When you give a person an excuse to do less than the best, often times they accept it as the norm. QA is a good example of providing an easy out. Why put the effort into checking your own code, ensuring what you do is acceptable and going out of your way to program defensively when you can have someone else do that often painful, trying to get toward perfection type of work….

I have no real evidence, but I’ve seen enough evidence to show that the number of QA resources is directly proportional to the poor level of coding. You might say additional QA people are brought in to compensate for the quality of coding, I think the number of QA resources is more driven by allowed budget and the higher the budget the power the code quality….sounds strange, but I really think it’s true.

I’ve always felt that a good QA group would indirectly contribute through audits and improved processes, however – in most cases – they are designated as testers, fed bad apps after development mangling. So, at the end of the day, the hoped for gains from a QA group are often lost through the misuse of them and the re-direction of quality from the source of issues to the QA group who gets stuck at the end of the pipe instead of helping front-load quality. My suggestion: get rid of QA and lets see what the results are, I would wager improved overall quality within 30 days.