Planning is essential, plans are worthless. - Dwight D. Eisenhower

This from a man who ran the campaign against Nazi Germany, one of the greatest beach landing (remember D-Day) and a very successful management of often difficult allies. How can the typical project manager, even a PMI certified one, argue with him? You can’t and he’s right. The process of planning is essential because it provides you with (if done properly):

• Scope of the project
  
• Boundaries and key players
  
• Benefits and potential costs
  
• Risks and mitigation plans
  
• Process to manage change requests
  
• Key elements needed for success and a clear definition of what success is
  
• Who you team is
  
• Timeframe
  

NOW – that’s a lot of benefit coming from Planning, and if you do a good job, performing requirement and design reviews (#1 Risk according to Capers Jones) – you have just put yourself in a good position to be successful. Now, if you’re like many project managers, you distribute your plan, store it nicely and have a fancy kick off meeting – to bad that by the time saved the entire plan, it’s out of date. Something happened: a business priority change, external impacts, team change – something somewhere making the perfect plan something less than perfect….when you hit the beach sand often gets in the eyes and causes some problem….SO, what do you do? The obvious is KEEP PLANNING, planning is not a onetime step, it a recurring , never ending – at least until the project is done and dusty. All I can say is – I like Ike!

The positive side of scope creep

You often hear complaints from developers and project managers about scope creep in a project. This is often pointed to as the #1 cause of project failure or delay…how could those dastardly sponsors add more…why didn’t they know this a year ago when we started this project….well the truth of the matter is – SCOPE CREEP IS USUALLY JUSTIFIED and the root cause of it is poor planning. WHAT? How could I say that…let’s look at some reasons for scope creep:

• Missing work – the actual #1 cause of project failure according to Capers Jones. Either through incomplete business requirements or project definition something that needed to get done was missed. Adding the MIA element back in is not scope creep, but scope discovery….better planning and requirement reviews would uncover these issues.
  
• Delayed project delivery – sometimes delayed project delivery is caused by priority changes or productivity issues (to aggressive in the planning phase), regardless, a delay in delivery means more time for external or internal business changes, resulting from a change to the project…scope creep? Yes, but for a valid business benefit reason.
  
• The world changes – even if the project is tracking good things happen in the world that require the business to shift its focus…offering 100 photo uploads? Well you competitor just went to unlimited uploads…can’t say no or you’re delivery may seriously impact revenue (aka you paycheck)….
  

What to do, what to do….first off, better planning and business requirement review will uncover required work removing the ‘hidden’ from becoming creeping. The next most important step is having a clear change control process in place so any requests coming in once the project starts are clearly tracked, assigned priority, review for impacts, etc…..scope creep…another project myth

Negative impact on software development from changing direction

There is no doubt that some projects need a change in direction, but the one thing to always remember is that no matter the intent or the reason for the change, there is a definite negative impact due to it.  It's pure physics - the object causing the change and/or the project impacted has some significant energy changed from movement to something else (heat?? I forget the law of physics...but there is one)....

What you need to consider is, if the change you are making will have an overall positive result upon the project.  Will the change correct the issues in a significant enough way to, not only address the short term issues, but ensure long term success.  Minor or major corrections have impact, making changes on a hunch or whim will increase overall project risk...choose your changes wisely and make sure you keep your focus on the big picture and not some ascetically pleasing one.

The Boss

http://www.guardian.co.uk/music/2009/jan/18/bruce-springsteen-interview

NO matter what your politics, you need to appreciate Bruce Springsteen's deep, strong, never ending willingness to speak his mind through his music and never questioning direct backup of it.

CYA - the hidden tax on projects

How much of our daily activities are spent with CYA activities? half? sounds crazy, but in many development groups CYA is the primary focus and directly promoted by Sr. Management. What type of activities am I talking about? Any that are primarily done to ensure that you have a log to prove that you are doing your job and any potential blame belongs to someone else. 

How does management promote this? When the focus is on blame instead of problem solving and delivery…when the focus is on discussing why things are not getting done rather then on what's getting in the way and how to remove the obstacles....

How much time is spent on CYA? It’s sometimes hidden, but it’s definitely exponential in growth. Once one person starts, it spreads like wild fire and emails, bug tickets, memos, meetings and more meetings….  When the focus is moved from problem solving to tracking and blaming the costs of running a project increase in relation to real progress..WHAT? what is it that you said? how else can you effectively manage a project if not assigning tasks, bugs, etc. to people and monitoring the results?  It's in the how it's done and your intention of doing it which starts to move the needle from making progress to CYA.  Let’s look at some examples:

Bug Tracking – when the goal is to assign the bug to someone else, a cold hand off without you knowing what the other person’s priorities are, workload or if there is enough information for the person to actually respond/address the issue…..a clear toss over the wall.

Email - #1 CYA tool – sending emails informing others of issues, upcoming tasks, Sr. Management concerns, etc….’gee – I told Bill about this a month ago, he should have handled it by know….’

How do we control it? With or without management – we need to focus on NOT giving into the blame game and CYA activities. Don’t contribute, don’t pass the buck, don’t directly respond to direct CYA activities, don’t point fingers – FOCUS ON SOLVING THE PROBLEM – be part of the team and realize you either fail or succeed with the team.

Good discussion

Do stackoverflow users agree with the NSA’s Top 25 most dangerous programming mistakes?

And why do modern programming languages not prevent these types of issues as a default? How far have we progressed (not even a spark, never mind a fire)

StackOverflow

I recently joined StackOverflow.com - a site put together by Joel Spolsy (Software by Joel) and Jeff Attwood (Coding Horrors).  The site's main focus is on providing developers a platform to ask specific coding questions and receive help, but it also allows for broader questions and anything IT related.  The differentiators from other like sites is it's use of 'reputation' to score you and others of the site.  The better your questions and answers the better your reputation.  Reputation is determined by some straight forward and some not-so-straight-forward algorithm...which is always under some adjustment...overall the site makes for good information and good reading.

Will electric cars be the major benefit from this recession

I'm no economic genius and have a limited understanding of the great depression, but from what I can glue together, there were some benefits from the prior Great Depression including:

• electricity to the outlying areas (West Va is used as an example)
• more federal government involvement in our daily lives
• the beginning of major infrastructure projects such as dams and roads

According to this NY Times article http://www.nytimes.com/2009/01/11/business/11electric.html?_r=1&hp 

it seems the US Car makers are 'moving' (or being moved) to focus on electric cars.  Prior reasoning to why they resisted ranges from pure economical (it costs more) to conspiracy (the oil industries didn't want to lose control of their power).  Could it be that the shear force of the Fed to move US Automakers to produce these electric cars cause the US to adopt them en mass - basically priming the pump for future consumption?  Is this a move from consumption based economic policy to supply based? Am I aimlessly rambling? Maybe....will this tendency of producing and therefore people consuming flow it's way into the normal business flow? and if so how does that change the typical project management planning process (defining benefits and costs)...

interesting graphical representation

The Bowling Pro

I recently went to a bowling pro shop (one of these days I'm going to get a bowling ball and join a league...must be a sign of my age) - and had a great conversation with the bowling pro.  He explained to me the various types of bowling balls, materials they're made out of, the impact based on the material, sanding and internal weighting, the need to know the lanes I would bowl at to determine the oil pattern an upkeep, the various grips and the impact of those on the hooking, how I throw and how I should be throwing the bowling ball, etc......He had charts of how the balls hooked down lanes that included variations based on the lanes oil pattern.....WOW....BASICALLY:

• tools sets (bowling balls)
  
• how to setup the tools based on the environment (grips, weighting, sanding and lanes)
  
• environment/culture (lanes, intended application, my goals)
  
• skill level (what am I capable of using and applying)
• application (how to throw the ball properly)
  

I realized pretty quickly that this person had more knowledge of his truly complex subject matter then I did on project management and more then most project managers I know.  He didn't evangelize one bowling ball, one grip or one ally/lanes over the other - he EXPLAINED the differences and the impact on the game....WOW.  He then went on to stress that over time I would change, my game would change and therefore my bowling ball should change and more likely - I would require more then one - as determined by the throw I wanted to make and the lane I was playing....This surly shows the skill set and work that needs to be done in the IT world, never mind project management.  My take aways:

• understand the goals
• understand the tools
• understand the environments
• understand the people
• apply what makes the most sense for that point and time

If I could attain this person's level of skill in my area...I would be pretty impressive.

(image from http://ourworld.compuserve.com/homepages/kennmelvin/Glossary.htm)

for you Hunter S. Thompson fans

http://www.sloshspot.com/blog/12-31-2008/Hunter-S-Thompson-Motivational-Posters-98