Project Management

Eloquence is eloquent

2011-07-06T14:09:00.002-05:00

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

2011-06-20T09:34:00.000-05:00

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)

2011-05-27T14:29:00.000-05:00

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

2011-05-20T10:10:00.000-05:00

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

2011-05-18T15:00:00.000-05:00

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

2011-02-22T11:12:00.000-05:00

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

2011-01-31T15:55:00.000-05:00

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

2010-11-17T19:33:00.000-05:00

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

2010-11-10T19:32:00.000-05:00

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

2010-10-28T09:01:00.001-05:00

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

2010-10-27T20:33:00.001-05:00

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

2010-10-22T19:20:00.000-05:00

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

2010-10-18T20:19:00.000-05:00

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

2010-09-29T09:11:00.001-05:00

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...

2010-09-28T20:00:00.001-05:00

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

2010-09-27T19:26:00.000-05:00

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

2009-12-17T21:19:00.000-05:00

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

2009-12-03T23:25:00.000-05:00

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

2009-12-01T21:10:00.000-05:00

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

2009-11-23T21:46:00.000-05:00

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.

You always lose in a zero sum game – always

2009-11-20T21:46:00.001-05:00

In the real world, where real things happen and theory hides in books there is little to gain from any interaction where one gains at the others lose. This applies directly to projects and project management.

Let’s look at a simple example: a project to improve market share in the hamburger market. The project includes creating a fancy website, iphone ordering and email marketing blitz…you currently have 30% of the market and hope for 40%...a healthy 1/3 increase. Could be worth an additional $50k a month if you get it…sounds beautiful. So you build the site, you create the iPhone app and you blitz the hell out of people until they start to associate you with the world’s best hamburger and you reach your goal….you might have spent $100k doing all of the including increasing your capacity to provide the additional hamburgers everyone wants. What happens day 2? When your competitor follows your lead or someone on the outside gets excited when they see the lines of customers waiting for your hamburgers? You didn’t really increase the overall demand, you just adjusted the finite demand…your initial costs and on-going support costs not just for the site and iphone app and email blitz, but also for the increased hamburger making capacity is still there as the hamburger seekers start to look elsewhere, the profit margins reduce and your new Mercedes is getting towed away by the repo man.

When you wrestle with any finite/zero-sum item you’re essentially spending to gain something that will eventually be lost – if you were able to increase overall demand, say from 1 in 10 people wanting hamburgers to 1.5 in 10 people wanting them, even if a share of that increase drifts to another hamburger provider you established a bigger pool to work from. The potential of going back to the demand where you started or even less is reduced.

What does any of this have to do with project management? Think of resource sharing, think of budget constraints, think of sponsor sharing – anyone or item that you have to timeshare with any other team puts you in a zero-sum game and continually puts you at a higher risk of failing at the end of the day. What you gain today in a finite pool will cost you more tomorrow to keep and cost you dearly if you begin to lose your share.

Escape Velocity – aka kick starting a project

2009-11-16T22:28:00.001-05:00

Starting a project is often as difficult as ending a project (successfully). In my opinion, a projects success is largely based on the psychology make up of the company and more importantly the direct team. A highly motivated, functional, capable team can perform wonders…a team without the cohesion, dedication and determination needed for the given project will easily and quickly fail. One of the critical stages in a project is the start of one, a given project that is delayed, pushed to the side, ignored, frowned upon by management and/or delivery team will fail before it starts – how motivated can a team be when they are given a project no one wants or cares about, a self fulfilling prophecy. To help ensure a successful project delivery, a good project manager will recognize the need to get the team ‘pumped up’ about what they are doing, motivate them from the start, aggressively start the project and do what is required to keep the momentum going…just like basic physics, a stationary or slow moving object requires more energy to move…a project that is blasted off, heading in the right direction and one where all team members are locked in step will be have a much higher potential of success…no planning, Gantt chart print outs, pounds of documentation will replace the team’s determination positive or otherwise. Projects succeed by the will of the team – period.

Old technology is everywhere

2009-11-05T21:31:00.001-05:00

I’ve been through the Old Iron Mainframe to Mini to PC transition, the standalone computer to everything/everyone connected phase, the computer as a tool to the computer is everything transition and now I’m seeing the computer is everywhere/everything to the smart phone switch.

Just recently I finally broke down and brought myself an iPhone. The famous, mind numbing, can do everything device that I thought was over played/over hyped. Well, I was very wrong and I am now realizing the smartphone switch that is/has-been happening very fast and very dramatically. Everyone is connected to everything from everywhere all the time. There’s good and bad in everything, but lets focus on the good:

no more missed calls or being out of touch
no more being lost
no more not knowing what’s going on from your friends level to the international level
the ability to shop smartly
the ability to plan smartly
the ability to adjust quickly and inform all
the ability to pay without cash or card
the ability to be entertained anywhere
storing memories, sharing experiences

Basically anything today that you have to ‘go to’ to use is being removed to be with you – or part of you. It’s an amazing shift, bigger then (but because of) all prior technology shifts over the last 50 years.

When the client is wrong, everyone is wrong

2009-10-29T22:18:00.000-05:00

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

2009-10-26T19:46:00.000-05:00

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

2009-10-21T22:35:00.000-05:00

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

2009-10-19T21:26:00.001-05:00

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!

2009-10-14T20:47:00.002-05:00

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

2009-10-09T20:47:00.000-05:00

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

2009-10-02T21:26:00.000-05:00

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

Can Project Management survive Anarchy (aka Scrum or KanBan)

2009-09-30T21:38:00.002-05:00

Anarchists are those who advocate the absence of the state, arguing that common sense would allow people to come together in agreement to form a functional society allowing for the participants to freely develop their own sense of morality, ethics or principled behavior. (via http://en.wikipedia.org/wiki/Anarchy)
Question: Can Project Management survive Anarchy (aka Scrum or KanBan)?
Short answer: A good Project Manager Can

I am (always have been) very pro-Agile, especially those who adhere to the base Agile Alliance Manifesto. (http://agilemanifesto.org/). Who wouldn’t support it? I mean really support it?
Short answer: Those who feel threatened by lack of control…

In my opinion, a GOOD project manager is a person who helps in any way to ensure business value is being provided. For those who feel some form of anarchy is needed to shake off the shackles of corporate over management, I’m with them. HOWEVER, in my experiences, those who push the most to shed the chains of corporate oppression often have their own chains in the making, something to be very wary of when supporting such a movement. The best approach is to uncover the underlying drivers and realize that at the end of the day we’re all humans and we all tend to make the same decisions as those before us (in other words, people who seek freedom of choice often try to bind others to their preconceived choice).

What is this blog post about? My on-going discomfort with where Scrum, KanBan and like movements are going, more about putting a certification business model in place than actually providing a path for improvement. I always get comfort in reading Kent Beck or Ron Jefferies posts, they seem to keep to the original goal of the Agile Manifesto where others tend to seek monetization for a recycled idea with a different sounding name.

I got the Wave

2009-09-29T19:01:00.000-05:00

http://www.cnn.com/2009/TECH/09/29/google.wave.beta/index.html
http://www.pcworld.com/businesscenter/article/172822/google_invites_more_testers_to_ride_wave.html

Evolutionary more then revolutionary and I think (once I get use to it) that it will set the pace and direction for other major communication tools. I've always felt that IM and Email are basically the same, and any way to easily track communication, continue the conversation and add to it would be GREAT! Google Wave moves in the right direction. There's potential for some information overload...but it all comes down to how people use and adopt to it.

WOW – Twit.TV/Floss Weekly with Linus Torvalds

2009-09-28T21:41:00.000-05:00

Floss weekly hosted by Randal Schwartz and Jono Bacon is kicking up some great shows. This week’s show is an interview with Mr. Linux - Linus Torvalds. As Jono Bacon said ‘…opinionated without being an ass..’. Not a deep insightful discussion on Linux, but a GREAT discussion with a leading software developer and some of what makes him who he is. A must listen to for anyone interested in IT.

http://twit.tv/floss88

Alan Turing - hero

2009-09-27T07:38:00.002-05:00

Thank you John Graham-Cumming for bringing Alan Turing's story to light and petitioning the government to do the right thing!

http://www.twit.tv/213

http://www.theregister.co.uk/2009/08/18/turing_pardon_campaign/

Kent Beck on FLOSS Weekly

2009-09-25T19:35:00.000-05:00

For those of you who don’t know who Kent Beck is, well its time to learn: http://en.wikipedia.org/wiki/Kent_Beck. Basically he’s one of the founding fathers of the Agile movement and the person behind Extreme Programming (XP) and all that goes with it…a real IT hero.

Kent was recently featured on FLOSS Weekly a great podcast about the open source community: http://www.twit.tv/floss87. This is a must listen to show, topics range from his view on Agile, Test Driven Development (TDD) and open source…all interesting and controversial points. What really caught my attention and reenergized me was his comments about a programmers need to take responsibility and to be accountable – plain and simple, something that every developer should reflect about in regards their dealings with others. His focus was more on the soft skill arena (psychology) and how it plays into the maturing of a programmer…

Dr. StrangeFramework or how I learned to stop worrying and love the layers

2009-09-23T23:20:00.000-05:00

Part 6 – Wrapping up
I did not cover all the layers (not even thinking about down to the linux kernel) and did not go greatly in depth into any one of them…I just wanted to provide an overview of the layers I encountered/put-in-place in the development of a prototype that may someday become the next open source project management tool. My overall feeling is that frameworks FORCE you to code in a standard way providing FREEDOM/FLEXIBILITY to focus on the product being delivered and those corners of the code where 80% of the complexity is (which sometimes needs to be handled outside of the various framework/layers). I w as happily surprised overall with my ability to decouple and with the reduced coding required to accomplish what it is I desired to do…

Dr. StrangeFramework or how I learned to stop worrying and love the layers

2009-09-21T23:19:00.000-05:00

Part 5 – ORM
What is it? I don’t think there’s any definitive answer, but basically ORM (Object Relational Mapping) abstracts data into objects (or attempts to) – so multiple tables providing data to represent a single project is treated as a single object with in the code: project name, project tasks, project notes, etc. each stored separately in the database (RDBMS) becomes a set of related objects within the PHP code…what my hope was, was that DataMapper would provide the interface to define the data layer and then kick back a hierarchical single object (Project) that would provide methods to access the underlying related data (project notes, etc.)…well, it did make accessing and manipulating the data easier – the top-down object hope was not there (could be my misunderstanding of ORM OR the difficulty in providing it). Once again following a framework forced me to setup the various data tables in a standard format and it did handle all of the underlying SQL/DB requirements and probably reduced my code by half (at least). Without having a LARGE database, its difficult for me to say what the performance impact is…I would assume there’s some impact…but I’ll leave that to others to provide the insight on…next, wrapping up

Dr. StrangeFramework or how I learned to stop worrying and love the layers

2009-09-19T23:19:00.000-05:00

Part 4.5 – the PHP Framework
Before moving on to the data layer, I first need to discuss the PHP Framework. I’ve moved from no-frameworks to frameworks for everything – WHY? Simple, it forces you to code to specific standards making the code cleaner and more maintainable. Frameworks also reduce the amount of code that has to be done – the less coding the fewer bugs. The first real framework I’ve used since web coding was CodeIgniter (http://codeigniter.com/) – about a year ago I decided to try a MVC framework (Model/View/Control) and did enough research to determine that CodeIgniter was stable enough and flexible enough for me…so far I’ve been very impressed with it and the associated community (a very important thing to look for – without support the best framework is useless). SO, to move on with the story, without thinking twice I used CodeIgniter for the PHP framework, the one dissatisfaction I had was the data model layer, I wanted something more than creating SQL code and returning array bound data…I wanted ORM (Object Relational Mapping) which I was hoping to use to reduce the amount of manipulation to set up the arrays to feed to the json encoder. It didn’t take long to find DataMapper (http://stensi.com/datamapper/) – an add on for CodeIgniter providing the ORM layer I was looking for. ..next step – ORM

Dr. StrangeFramework or how I learned to stop worrying and love the layers

2009-09-18T23:18:00.000-05:00

Part 4 – json
Json is basically a universal standard way of formatting data (http://www.json.org/) which provide some benefits over XML (still being argued somewhere)…why not XML? One reason was that jQuery directly handled json and another was that everyone is talking about json….simple as that. In Part 3 I discussed how I started the json approach using static json data pages, the next step was to move from static to database/code provided data. Creating a json output in php is relatively easy (depending on the PHP release that you are on) – there’s a simple function json_encode(data) where data is typically a series of arrays/sub-arrays containing the data you want encoded. So, json encoding was the easy part, the difficult part was getting the data in the the array/sub-array/sub-sub-array layout that you wanted…next step, the data layer.

SANS - The Top Cyber Security Risks

2009-09-17T19:38:00.000-05:00

Interesting paper on security issues: http://www.sans.org/top-cyber-security-risks/

Dr. StrangeFramework or how I learned to stop worrying and love the layers

2009-09-16T23:17:00.000-05:00

Part 3 – decoupling
To keep the layers decoupled as much as possible, I decided not to have any PHP code directly populate data within the page ANYWHERE! No matter how easy it is, the complexity and maintainability is impacted when you do this – you end up with HTML/jQuery/PHP code all over the place in the same code file…some people use Smarty or like frameworks, but all they do is basically add another layer without reducing the coupling. SO, I decided to use json…I started with some static json data pages and used jQuery (THE BEST) to read the data, parse and populate the page, overall a very pleasant experience compared to what I thought it would be. The toughest part was properly formatting json, once done I was satisfied that for the most part the presentation layer to the application layer were decoupled…next step, json

Dr. StrangeFramework or how I learned to stop worrying and love the layers

2009-09-14T23:15:00.000-05:00

Part 2 – there’s no end like a front end
I wanted to focus a bit on the user interface, my prior attempts using trees and such were ok, but just ok. I knew I wanted to use base html/jquery (no Flash), so I started at jquery.com, looked at some of the addons and took a swing: http://www.itprojectguide.org/projectmatrix/ci171/matrix. I only focused on what I considered the main screen, the project page and overall I think it’s reasonably user friendly (something that might change once I add in all the base project related fields). The layout is basic, using tabs for projects and sliding panels for project details…seems like a simple/clean design. The biggest challenge was uniquely identifying fields by project, so from tab to tab the changing of a ‘start date’ field for instance would only be updated for that specific project. As a new project is added, a new tab created with the project identified fields…as always jquery made most of the work easy and coding amount/time small….next step, decoupling

Dr. StrangeFramework or how I learned to stop worrying and love the layers

2009-09-12T23:00:00.000-05:00

Part 1 – the setup
I haven’t had a heads down coding position in years, however I continue to develop small websites and ‘play’ with code on side projects and hobbies. A good part of the fun is pushing myself to learn new technologies and approaches, the days of happily coding in C, C++, VB or classic ASP are long gone.

I’ve worked on two open source project management tools (info can be found here: http://itprojectguide.org/main/products/Home) the first a branch from another open source group and the second an attempt to provide a better interface and a better code base. I learned a lot from both, but was left unsatisfied, mostly due to the design, but also the cumbersome underlying code, PHP can be pretty messy if you let it. One of the things bothering me the most is the coupling between the different layers (DB to PHP to HTML) and the need to refresh pages to display updated data (loading a heavy page of about 80k to add 100 additional characters seemed a bit to much).

There are MANY options to writing code for a web site, PHP being the most popular since its probably the easiest to learn and abuse…I often hear Python/Ruby coders trash PHP all together, the way I see it, any language can be distorted, some languages make it easier than others, but it’s the developer who makes the difference, I’m more than confident that a good programmer can make clean, effective and maintainable PHP applications – as clean as Python or Ruby can be….next step, the front end

When you plans are right, but have nothing to do with reality

2009-09-10T22:40:00.000-05:00

I’m just starting the book ‘The Guns of August’ by Barbara Tuchman – about the planning and first month of WW I. The most interesting point so far is that the French Plan (Plan #17) took no account of actual intelligence gathered about what the Germans planned. The French basically developed a plan based on current theory and molded what the Germans would do to fit into that theory (‘no way the Germans would march through Belgium and attack out exposed flank…no way…’). Sounds familiar right? developing a plan based on some current theory, regardless of what facts about known…probably a good example that project managers encounter every day is the time required for testing – break/fix. Forget about the last 10 projects that required the same effort to QA/break-fix as what the coding took, let’s assume this time the QA/break-fix effort will only be 25% which is perfect since it will allow us to release the product in time for the big holiday season….yep, planning and execution are truly different when you refuse to take fact into consideration.

Seeking the just good enough?

2009-09-08T23:03:00.000-05:00

I recently read through issue 3 of PragPub and found the article Clone Yourself (http://www.pragprog.com/magazines) – the focus was suppose to be on (I think) building a better career through following the pattern of perfect process…one section deals with the idea of not getting the best person for the position, but a person that’s just good enough given that you have the right processes in place to ensure their success (if the process is good the person can be mediocre). I’m not sure if there has been any subjective research on this matter – but I would have a difficult time agreeing to it. The author references some past experience where they got the best and they didn’t work out, I would say that perhaps the definition of best was incorrect, what do I define as the best person for a job?:

someone who is enthused about what they are doing (gotta love the job)
willing to do what it takes to get the job done
great communicator
team player, but not a compromiser
independent worker
intellectual capacity for the job (knows and/or ability to learn)

Some traits I would think disqualifies a person for a job:

inability to work with others – at any level
very narrow skill focus – unless the skill is so narrow that it requires such a narrow focus
to many preconceived, unshakable, predefined concepts

Overall, the idea that a person is only needed to follow a set of processes leads me to think that the job is probably not a real development position where something new is being developed, but where the job is no more involved than a data entry position from the 1970’s. No matter how hard PMI or Agile Alliance or any other group tries to define a set of steps to ensure success of a building process, they have not yet succeeded and as far as my theoretical thinking can take me, can never succeed since they would have to finitely define every potential step for every development effort that has or WILL take place…even Madame Marie on the Asbury boardwalk cannot make that assertion.

Another example of open source knowledge

2009-09-01T20:33:00.000-05:00

http://www.scribd.com/doc/8545174/Whys-Poignant-Guide-to-Ruby

If there's no incentive to selling books/knowledge (talking $ here) then people who have a tendency to want to write them will find other avenues (aka the web) - this is one great example of that. Not only is this is a great into to Ruby its a great read...

To fast is sometimes too fast

2009-08-28T20:29:00.000-05:00

Some things need time to jell and form, like new project management theories and ideas. It seems recently that as soon as someone burps an idea there’s a website, entry in Wikipedia and money making organizations popping up to support it. It’s always good to think of improvements and give them nifty names as reference, but there also needs to be time to let them form and see if what was hoped for is realized. I’m all for getting in at the ground floor and making a mint on a new idea, but getting in before the ground floor is set…and before the idea is fully formed…it reminds me to much of the good ole’ traveling medicine shows.

(image from: http://www.timboucher.com/journal/2007/11/26/medicine-shows-traveling-salesmen/)

Happily looking stupid

2009-08-27T10:38:00.000-05:00

Being able to look stupid has many advantages in project management

I’ve recently been thinking about one of my biggest strengths: willingness to look stupid in front of people. I think I first realized this power when I first started to play the harmonica with local bands at bars (some of which were actually ok as long as I was outside the bar)…

Being comfortable with looking stupid has allowed me to:

Ask the stupid question that everyone think everyone else knows, but no one really does
Question why the go-live dates are being pulled in, when all indications show that the project delivery dates should be moved out
Ask a top developer why the suggested confusing/mind-boggling approach is the best
Not show up for mandatory meetings, when the meeting agenda is about setting up other meetings or when no agenda is present
Not stay late when there’s no other reason than to look good in front of the boss
Ask HR why such wonderful company policy about safe/happy work environments and balanced work/family time is never really inforced
Question why cost cutting is the focus instead of opportunity taking
Keep trying to promote change based on issues and not symptoms
Ask why exceptions that happen all of the time are considered exceptions

Looking stupid has not always been easy, but as time goes on and I feel more confident in myself the more looking stupid seems to be the right thing to do

change to IT Project Guide - Open Source look/feel

2009-08-10T13:19:00.002-05:00

I haven't really updated the IT Project Guide - Risk Management project in a while (outside of some reported bugs) - thinking about moving to a new look: http://sourceforge.net/projects/itpgrm/

compare to what it is now:

http://itprojectguide.org/PMBase/risk/home

??any thoughts?

process corrupts, absolute process corrupts absolutely

2009-08-05T21:00:00.000-05:00

Why are there continued changes in IT project management and SDLC processes? And why can’t developers and project managers define a single process that both agree on? Are there that many conflicting goals that prevent this from occurring? I think the root cause is the idea that a single process can be defined and put into place today, based on yesterdays findings and that will be beneficial tomorrow. No plan to put a stagnant process in place will never work, problems change, environments change and most importantly people change.

I think this is the root cause for continued process change, for example KanBan, which is based on Toyota’s car manufacturing process, just as Six Sigma was developed by a Motorola process break through. If you look closely enough, new processes are old processes re-purposed, re-named or slightly re-factored…why? I think the reason is that, once a process is put in place it goes through a phase of being formalized, dumb’ed down so everyone can follow, forced on to every new project and (most unfortunately) used to measure people’s ability and commitment to the company….exactness to steps instead of intent is followed. As the process becomes more out of step with current needs of both projects and people, they are targeted as being old and wrong and new ones are ‘discovered’ and implemented.

We need to get everyone (aka management) in line with continued process improvement (or whatever the new term for that is) and ensure that a meta-process is in place to continually review and improve and replace as needed.

KanBan - http://agile.dzone.com/news/introducing-kanban-flow-and

(image via: http://timmonsgalleries.com/FA-rep.html)

Netflix Culture Presentation

2009-08-05T11:38:00.001-05:00

Great presentation with a lot of great ideas!

Culture

View more presentations from reed2001.

How we learn - reading other people's discussions

2009-08-04T09:33:00.002-05:00

I've been following a great discussion on KanBan at: http://tech.groups.yahoo.com/group/extremeprogramming/

you have some VERY INTERESTING people involved including Ron Jefferies and Kent Beck...I would highly recommend any interested in hearing some top authorities discuss an important item (project approach) to join and listen in.

Front loading success

2009-08-01T21:00:00.000-05:00

In a recent article, Tom DeMarco stated that Software Engineering is an idea whose time has come and gone, basically stated that heavy management /oversight is mostly needed for projects that have minimal benefit and those projects with the most to offer require less…and that the real effort should be focused on ensuring the right projects are selected and then on anything that will help those projects have the highest probability of success.
If that’s true, than we need to ensure that we focus on ensuring that all processes in place allow for the least friction to the project team while ensuring focus is on front-loading success factors into all projects: from selection of the project, team selection and management selection. Just as QA’s real benefit is ensuring quality processes are in place, from requirements writing to delivery, a project manager’s real benefit to an organization is in ensuring the right project is selected and that it is given the proper start in life to succeed…unfortunately most PM’s are still looked to for delivering daily project updates and bad news about slipped dates. (just like QA is looked to performing post code complete testing)…
No matter which project management process or SDLC is selected, no matter what quality team is used or outstanding platform – a ill conceived project will fail and potentially cause collateral damage to the business.
We, PM’s, need to remain open minded to new ideas and be brave enough to speak out when needed.

Tom DeMarco Article: http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf

(image from www.ac-orleans-tours.fr/.../insurgent3.htm)

They built it the way I would have

2009-07-28T22:00:00.000-05:00

Just as a disclaimer – I’m as Smartsheet associate – someone who could potentially make $ when someone follows a link I have and purchases the use of Smartsheet, either it hasn’t happened yet OR Smartsheet is holding out on my million $ check – whatever case has no impact on the following.

I’ve been involved in two separate open source project management tool projects, together they have about 5,000 downloads from SourceForge and neither one would I really use in a business environment (but they were great for learning php, CodeIgniter, SourceForge and 100 other interesting things).

When I think project management tool, I think of:

ease of use
ability to easily modify what information gets captured
NO Gantt charts
enhancing communication
single stop for all project related information

The most effective tool I’ve used, prior to Smartsheet, was a spreadsheet (MS Excel and Google Docs) – both provided the flexibility and control I wanted, but neither provided real automated reminders, document storage or ability to easily modify look/feel…

When I first started to use SmartSheet it was a spreadsheet on steroids, but mostly a spreadsheet. Over the last year a lot of new functionality was added, including the ability to perform some functions on each cell. The overall user experience is simple to the touch, making one think that there’s little power under the hood. HOWEVER, I’ve come to rely heavily on it (even if others have not – yet). Adding new columns, changing drop down values, add sub sub sub tasks, having dates programmatically change based on prior tasks date changes, timed or event driven email updates, reminders, etc. are all there. It take the hassle out of working with a plan and lets one focus on working the plan.

I’ve worked with and tried about a dozen other PM tools…but I’m still not seeing anything that would compare to Smartsheet….at least for my current needs.

Improvements through dumb’ing down (aka simplification)

2009-07-19T21:00:00.000-05:00

The Wii, Google’s planned new OS, the web interface (compared to client/server), PC’s, the iPhone (compared to laptops) all have an interesting thing in common – improvement through simplification (aka dumb’ing down)…it seems to be a cyclic experience, where things (anything) grow in complexity until someone rediscovers the base benefit, removing the excess/gold-plating and providing a major improvement through reductionism rather than increased functionality…pure beauty.

I think we’ve seen the same process take place a few years ago with XP/Agile and since then the increasing complexity being added to the base Agile theme.

Lessons learned: Look to dumb’ing down any existing process, don’t listen to:

that’s the way its always been done
if we just add this one thing it would make everyone’s life better
I think JoJo the monkey boy from Finance uses that application…so we need to spend $1 million when upgrading to support it

Be brave and cut the phatt

Only 8 seconds and in 3rd place

2009-07-17T21:00:00.002-05:00

I haven’t been following this year’s Tour de France (http://www.letour.fr)closely, but I’m still aware enough that Lance Armstrong is in it for his potential 8th win, a huge record. As of today, he’s standing is still 3rd and ONLY 8 seconds behind the lead – this is the 10th leg of a 20+ leg race…my first reaction is ‘only 8 seconds..not bad…I’m sure he can make that up…’ and its 8 seconds out of a total of 43+ hours of racing– but in reality, if it was really that easy he would be in the lead and not 3rd place and unfortunately it could be a good indicator that the rest of the race will reflect the current standing.
Lesson learned: if you’re behind in schedule assume that unless you change something, you’ll remain the same ration behind (or worse) for the rest of the project. Don’t fall into the ‘we’ll pick up speed soon’ trap, even if you’re just a little behind schedule…if everything was going as planned or better, you wouldn’t be behind, even by a small fraction (especially since we all tend to heavily buffer the schedule).

Don’t Hope
Don’t Ignore
Don’t expect good things to happen on their own…

Be alert to your own checkpoints and flags, that’s why you put them in place and react appropriately

Software Engineering: An Idea Whose Time Has Come and Gone?

2009-07-17T13:21:00.000-05:00

A very important read:

http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf

Looking in from the outside

2009-07-14T10:30:00.001-05:00

According to the stats, 2 in 3 projects are not considered successful, something I think all of us would gut feel agree with. Out of morbid curiosity, I’ve been following the outward signs of a long-running,yet-to-be-announced project failure in the CMS world…

late 2006, initial discussion of the upcoming major release 3.0
early 2007, sneek preview at a major conference
early 2007, announcement that the current version will have an interim release to correct security issues
mid to late 2007 – all quiet on the release 3.0 front…to quiet
early 2008 - announcement of difficulties and long weekends of work
mid 2008 – more previews, a demo site and a planned go-live in a ‘few short months’
late 2008 – announcements of what the new version will not support
early 2009 – commitment to more timely updates – and the quiet again
a little bit later in 2009 – discussion of a beta
now…..who knows

The above is a rough timeline of events. From the communication (mid 2006) to the most recent the indication was that there was only a ‘few more months’ of work prior to the v3 release….a few months of work that has so far taken 3 years to get complete. Sounds to famliar...

I’m just wondering that with the current number of open source communities, if there is some valuable lessons to be learned from following their progress……..

When in doubt stick it out

2009-07-13T21:00:00.000-05:00

There’s an old saying in boxing (or really any martial like art) that ‘when in doubt, stick it out’, mostly referring to throwing a jab instead of doing nothing in order to keep the opponent busy. Well, the same holds true for project management. It’s always better to send out a ‘straw man’ (rough sketch/best estimate) then nothing at all. It provides a base to start a discussion from, provides a catalyst for others to react to, displays some form of action and direction AND above all sets a tone for the project. Don’t hesitate or be to conservative, others will take that as the tempo for the project and follow suit. Afraid that what you send out will cause a commotion? Well….that’s part of the PM job, isn’t it?

(image via: http://www.boxingdaily.co.uk)

Edge cases – here be dragons

2009-07-08T22:47:00.001-05:00

Let’s be clear about one thing: there is no such thing as perfection…which inversely means that there is always imperfection. The land of imperfection is a place to tread softly. Imperfection is always rampart in project assumptions and those areas where developers feel the most comfortable: clearly defined logic. There are always edge cases, the non-norm where more mystery then factuality exists, always logic that tries to account for everything, but…….never seems to be able to. Technologists may try to convince themselves that everything is definable and that everything definable is programmable and everything that is programmable is complete…but the base assumptions are always wrong, nothing is completely definable, nothing defined can be completely programmed and nothing that has ever been coded has been complete.

Where is this going………..

A project manager needs to be aware of those who start to wander in search of perfection, such as:

100% uptime (or even 99.55555%)
Complete data integrity
Performance never exceeding some sub-second time
Ability to identify people from bot
Ability for bot to replicate people
Performance testing
100% geo coverage

And steer the people back to safe shores where obtainable objectives are achievable. Stay aware, watch for developers straying and sponsors espousing grandiose ideas. You can’t stop the explorers and doing so might stop some new discovery…but don’t let main line business projects go in search in areas where dragons abound.

New Real Estate Open Source project – help wanted

2009-07-08T08:51:00.000-05:00

OK, so I’ve got a new scratch to itch, this time it’s real estate related. I’ve worked for real estate companies for about 10+ years and always felt that the life cycle, though understood by many, was never implemented. Most people begin their real estate search on the web and within the first 2 weeks of their search begin a relationship with a real estate agent. Most often the relationship with the agent is through a referral (family or friend)…So…search the web…personal referral to an agent…why doesn’t the web search lead to the client/agent relationship? Simple – most real estate sites are listing focused, which is nice, but does not provide the easy transition from interest to relationship building required for most real estate transactions. One of the major drawbacks into finding a real estate agent is the lack of information about the agent, typically it’s just a picture, name and phone #. What I would like to do is build a product where the focus is on the agent, providing relevant information for the consumer to select one and providing the agent with a social network environment where they can nurture the relationship…here’s my first pass at the spec: http://itprojectguide.org/myAgent/myAgentv1.pdf

And SourceForge site for the project: https://sourceforge.net/projects/myagent-re/

If you’re interested let me know. meade.rubenstein@yahoo.com

A fish DOES rot from the head down

2009-07-02T21:00:00.000-05:00

After confirming with a reliable source (Myth Busters), I can confidently say that a fish does rot from the head down (with from disclaimers about the fitness of the dead fish):

Sunfisher
Senior Member
Registered: 09-27-08
Posted 12-10-08 12:01 AM
Living on a lake in MN, I think I am qualified to explain this one. The skin, scales and the rest of the outside a fish provide a barrier that inhibits decomposition. If this barrier is damaged anywhere it will appear that decomposition has started at that point. If the fish is undamaged, the eyes are usually the first thing to go.
Link: http://community.discovery.com/eve/forums/a/tpc/f/9701967776/m/5641933599?r=5641933599#5641933599
(you might have to log on to view)

So, how does this apply to an IT Project? There are probably a few ways you can apply this metaphor, the one I think most applicable is that a project will rot from the Initiation phase down. If you don’t get the initiation right, which includes: goals, scope, constraints, involved people – than the rest of the project has a higher risk of rotting.

Wireframe – when less is more

2009-06-30T21:00:00.000-05:00

The goal of a wireframe design is to provide the review with a sense of the overall user experience, ensuring that what’s delivered is functional, usable and attractive…period – nothing else, not color schemes, not what images to use, not wording, not the glossy look and feel of a finished product. The wireframe needs to be closer to an old fashioned architectural diagram than a glossy magazine, the most essential reason behind this is to help the review focus on what the effort is trying to convey. A simple experiment (mind experiment if you want): put two diagrams in front of any person, one a black/white sketch and the other a mocked up webpage with deep rich colors and interesting images and see where the focus of the conversation is…pretty obvious and a pretty entry level IA (information architect) mistake.

I put most of the blame for poor IA on the tools being used, use photoshop and you get gloss, use visio amount of detail information that you build in comes at a high price of time and effort – a good IA tool needs to provide quick, easily updatable, clean designs…just so happens I’ve recently come across a wireframe tool that provides the clean, sketch like look along with the ease of use that I’ve always hoped for - Balsamiq Mockups: http://www.balsamiq.com/ Not free, but worth the $’s. I was able to sketch out a 20 page site in about an hour, go back through and refine in another hour…the ease of the initial creation invited revisions…making for a better end result.

Software development isn’t the only thing to suck

2009-06-26T07:00:00.000-05:00

Intro to the Boeing Dreamliner story: http://www.msnbc.msn.com/id/31504462/ns/business-aviation/

Boeing Dreamliner - 2 years late and a lot of excuses (via http://en.wikipedia.org/wiki/Boeing_787):

blaming a shortage of fasteners as well as incomplete software
cited problems with its foreign and domestic supply chain for the delay, especially the ongoing fastener shortage, the lack of documentation from overseas suppliers, and continuing delays with the flight guidance software
said that insufficient progress had been made on the factory floor to complete work that was originally planned to be carried out by suppliers
unforeseen delays
another delay, this time caused by the incorrect installation of some of the structurally important fasteners
will face additional delivery delays of up to six months, because Boeing is not expected to reach its target production rate
stating that the first flight is postponed "due to a need to reinforce an area within the side-of-body section of the aircraft"

Sound familiar? I’m no critic and don’t have any airplane building experience (outside of models), but it’s sort of nice to hear that industries other then IT/software have their problems too. So, the mighty engineers aren’t so mighty after all and the giants of efficiency and getting things done also fail. It’s like dancing on someone else’s grave…but, let’s get the dance over and see if there are any lessons here.

To many new things:
new technology (carbon fiber) + new process (offshore’ing the work) + new relationships (either new offshore companies or at least new types of interactions with them) = trouble.
To many new factors to properly control. Maybe the offshore activities should have been tried with existing manufacturing and any new R&D type of product first needs to be developed onshore with known/skilled resources.

If you’re drinking a gallon of coffee don’t blame the dog barking for lack of sleep:
Fasteners, fasteners, fasteners – seems to be a recurring theme (at least on the face of it). If the same issue keeps arising, make sure it’s the root-cause issue and then attack it. In the IT world you often hear about Quality issues or integration issues and then management focusing on hardware (or whatever they’re comfortable discussing) to correct it….find the real problem, doesn’t matter if its within your comfort zone, and deal with it.

Most of the times, you don’t need a crystal ball:
If you’re having problems throughout the entire project, don’t wait until the end to tell the users that their expectations are not going to be met. Fewer features, lower quality, slower performance or whatever the impacts are from a problematic project need to be clearly communicated out to the sponsors and clients as soon as possible – but not before the confidence in being able to deliver to the new date and expectations level are set.

Security - don't start a project without it

2009-06-13T20:57:00.001-05:00

Alleged Hacking-Terror Effort Thwarted

All Pain and No Gain

2009-06-12T21:00:00.000-05:00

Clients are still unhappy, your manager is not patting you on the back, the developers grumble about everything, the projects are still not getting done timely or with quality and you’re running out of beer. Project Managers often go into new situations with the best of intent only to find that process changes provide poorer results then what existed…why is that? In most cases the answer is simple – the wrong problem was addressed. The Gantt chart, resource allocation , bug tracking, task management wonder tool was used like a circular saw in a ice cream shop – resulting in havoc, despair and unemployment.

Political, territorial, ego sensitive, insecure, unsure, over bearing people (aka The Team) who have trouble being in the same room with even themselves will have no problem entering time estimates in project plans or nodding their heads in process review meetings, BUT try to get them to truly change to a more productive and cooperative relationship with others, based on a Gantt chart, is like trying to pry a icy cold beer out of my end-of-week tired of the nonsense hands, it ain’t happening.

Rule #1 – know thy problem, don’t listen to people when they’re telling you the issues, LISTEN to them, are they naming names, are they talking about past attempts that failed, are they sneering at you, do they seem distracted, focused on everything but their area of responsibility, are they there or mentally removed? Look at people’s desks, how they interact, the environment they’re working in and how they treat each other. Do the managers provide clear direction? Do people show up on time OR at all to meetings?

Rule #2 – assume you don’t have an answer, don’t come into a situation with a answer before you really now the problem (go back to Rule #1). It’s easy to look back at historic events and come up with better plans (gee, if I was George Washington I would have purchased some of the new tanks to take care of the British…) THE tough part is coming into a situation not knowing how it’s going to turn out and actually making a significant positive difference. Spend time with Rule #1 before even thinking about the solution.

Rule #3 – communication and consistency, nothing unexpected should be done and whatever is done should be consistent. Let people know what your planned changes are, tell them what impact it directly has on them, tell them the truth and consistently apply the corrective actions – if there were no exceptions there would be no need for the rules.

Rule #4 – don’t back off, but don’t close your eyes to change. Change is tough, getting people to change habits is a painful process – search out the positive and acknowledge and reward it, search out the negative and apply the appropriate correction, don’t shy away from the job…and don’t close your eyes to the possibility that all of your plans are correct, be open to change and rethinking, but be cautious about any decision to move off course – over correction is sometimes worse than no correction.

Rule #5 – realize that it doesn’t end, there’s no end to improvement, there’s no end to doing things better there’s no end to problems….

Learning Python

2009-06-10T07:00:00.000-05:00

I’ve been spending a good amount of time recently learning Python. Why?

ego – I want to be able to walk the walk and speak somewhat intelligently with other tech heads
staying relevant – I have another 20-25 years of employment ahead of me…
seems like the new Java – I never learned Java (not sure why ) and always felt left out (back to #1 – ego)

As a project manager, my needs for learning Python are different than they would be if I were a developer, the level and depth of understanding are different, but the need to understand the basics and application are the same. I’ve always felt that a good project manager needs to have a good technology background, this provides for insight into development and a common ground for communication. Imagine a PM with mainframe and COBOL knowledge only talking to a 19 year old php/MySQL developer…could be lots of talking going on, but little real communication.

What does learning really mean? I’ve seen a lot of people learn a lot of things, but few actually gain an understanding and the ability to apply the learning. To me, the true test of learning is the direct application (base learning) and extrapolation (advanced learning). Reading a book, typing in examples and getting expected output is just the knowledge that there’s something out there – here’s an excellent Buddhist look into knowledge: http://www.sacred-texts.com/bud/mzb/oxherd.htm ..
Another aspect of learning is understanding WHY it’s important to know what you’re studying, why other people see it as meaningful (insight into others) and why it’s getting the focus. Much of which I’m still trying to get my hands around in regards to Python.

So, what steps did/am I taking in learning Python? Basic google’ing Python was the start, which quickly lead me to http://python.org/ - the official Python website. From there I moved to Active Python- http://www.activestate.com/activepython/ - where I downloaded the interactive Python interpreter (and later Komodo edit for a better editing environment). Having an interactive/interpreter made learning and experimenting a lot easier – typically a new language means a new IDE, finding a host or setting up a development environment, etc. – nice thing about Python (one aspect of why its getting the buzz) is the low pain threshold of starting. Being ‘old school’, I also purchased a couple of books – O’Reilly Learning Python and Expert Python Programming: Best practices for designing, coding, and distributing your Python software which I’m still reading. I followed the typical approach of skipping around to interesting sections and trying the code out in the Active Python Interpreter….another important source of help was StackOverflow (http://stackoverflow.com/) – tech heads ready to answer the most basic questions.

So, now for the good, bad and ugly aspects of Python – SO FAR, I see Python as a very clean, easy to use multi-platform programming language. In many ways it reminds me of Pascal, back in the 80’s (aging myself), a step in helping programmers program correctly. Being a new language, specifically developed for its currently environments, it does not have a lot of the quirks and kludges php, c# and other languages have (if I offend…oh well). The ease of learning (or unlearning and relearning) is there and the interpreter provides for ready/quick feedback. I’ve:

.played around with creating a UI (Windows) – not a pleasant experience
interacting with various data sources, like websites, files and databases – fun and easy
built classes, generator functions, modules – very easy and eye opening to the strength of Python

I see Python (my opinion) as a solid clean language – good entry for non-tech heads and experienced programmers alike (similar to BASIC), the typical evolutionary but not revolutionary steps of technology. Would I recommend it as a platform for development? Yes (depending of course on the actual needs), would I recommend it as a learning platform for new techies or those needing something more than excel – YES. I’m not sure of its stability or performance issues – but, seeing its implementations and uses would expect them to be at an industry strength level (outside of high use sites like Facebook – but I could be wrong).

Next steps for me include:

finding a project that I can use Python on (currently looking into creating an opensource requirements management project)
looking into Python web development frameworks (seems to be a decision between Django and Pylons)
still looking into the interesting python’ic aspects of Python. One pattern I’ve found interesting were the generators (using yield within a function) and redefining superclasses…huge improvements over what I’ve experienced in other languages…

If you’re interested in Python, I strongly suggest installing Active Python (about 5 minutes) and going through the Python.org tutorials…

The Product of a Self-Defeating Design Process

2009-06-02T04:15:00.001-05:00

Good article on why corporate culture is the ultimate deforming force

Project Management exercise from StackOverflow

2009-05-28T15:30:00.006-05:00

Here's a mindmap I put together based on a question from StackOverflow

http://stackoverflow.com/questions/922559/how-should-i-begin-this-kind-of-project

The Master and His Three Sons

2009-05-14T07:00:00.000-05:00

There was once a great master of kenjutsu (sword) renowned throughout Japan who, when visited by another great master, wished to demonstrate the teaching he had given his three sons.
The master winked at his guest and placed a heavy metal vase on the corner of the sliding doors, wedged it with a piece of bamboo and a small nail in such a way that the vase would fall on the head of the first one who came into the room when the door was opened.

While chatting and drinking tea, the master called his oldest son who came immediately. Before opening the door, he felt the presence of the vase and its position. He slid back the door, put his left hand through the gap to catch the vase and continued opening the door with his right hand. Then, clutching the vase to his chest, he entered the room, shutting the door behind him and replaced the vase; he came forward and greeted the two masters. 'This is my oldest son', said the host smiling, 'he has learnt my teaching well and one day he will undoubtedly be a master of kenjutsu.'

The second son was called and he entered without hesitating and only caught the vase at the last moment: it almost landed on his head. 'This is my second son', said the master, 'he still has a lot to learn but he is improving every day.'

Then the third son was called. Entering the room hurriedly, he was struck on the head by the vase. The blow was a heavy one but before the vase hit the tatami, he drew his sword and, in one quick action, cut the piece of metal in two. 'This is my youngest son, Jiro', said the old man, 'he is the baby of the family and he still has a long way to go.
______________________________________________

Question for the project managers out there:

Which son are you when it comes to risk management?

Value of Teams on mid-size projects

2009-05-12T07:00:00.000-05:00

There’s a gray area of project size (scope and complexity) that may or may not require a team to complete, this is the focus of this discussion. The determination of what that gray area is, is a completely subjective/fuzzy call by those in position to make that decision.
Personally, I have always leaned towards having the fewest people involved in any project, this is based on my feeling that any additional communication, management or human interaction than required exponentially adds to the risk level of the project – however – I might be wrong. What if the team is well established, mature and requires minimal management? (Ideal situation of course)…what value could having more people than required on a single project?

Higher quality product and more productive if an XP type of team programming is in place.
Chance to develop a Jr. member on the team
Continued reinforcement of the team model and on-going success record
Direct transfer of knowledge to a backup person

I’m beginning to think, with the right team, on a project that can be team-developed or is decoupled enough for multi-people to work on – the leaning towards more people rather than fewer is the right approach.

Ed Yourdon - Enterprise 2.0

2009-05-07T08:12:00.001-05:00

One of my hero's of IT....there's enough information in this presentation to keep a person busy and thinking for a VERY LONG TIME!

Enterprise 2.0

View more presentations from yourdon.

What Project Management Lessons I learned from watching bowling

2009-05-04T19:18:00.002-05:00

Bowling is one of the few sports I can enjoy watching and I’m sure it’s a sign of my increasing age. Here are some bowling lessons I’ve learned that I think are directly applicable to project management:

You’re known for your last lose (failure) more then all the prior wins
No matter how good you bowl, know the lanes, no matter how many prior frames you had strikes in, the next frame is an unknown…
Few bowlers bowl a perfect game
The professional bowlers don’t look at each other much….they tend to focus on their own game and not how the other bowler is doing
No matter how geeky your shoes look, how out of date your shirt is, if you’re good people will pay you and others will watch in admiration
One bad frame does not always mean a lost game

Standish 2009 CHAOS Report – what could it mean?

2009-05-01T07:00:00.001-05:00

Like any other report, The Standish CHAOS report will have it issues – what defines a failure? How do you validate the sources? What does it really mean to fail or succeed? Does this represent to broad or to narrow of a segment?

These are all good and valid questions, to me the most important is the report data gathering and reporting consistent with prior years? The final #’s have little relevance (to me) compared to the overall trending….and the overall trending is interesting - more projects are failing this year than last. A lot can be read into that, here’s my take (assumptions):

As the economy continues to slow (or remains slow) the better managers will cancel the less important project, focusing on the key business drivers (end of day a good thing)
Companies are cutting resources, causing the remaining people to be overloaded causing lower quality deliveries (a bad thing)
People have more of a negative view and will tend to be more critical of what is being delivered and lean towards reporting failures more than successes…one of the bigger issues with any subjective type of reporting – BUT one that can be understood and used to adjust the findings.

My view of the report is that it’s a great value and solid indicator of what is happening in IT – my view of IT based on the report….we need to get a lot better 32%...that’s a failing grade in my book.

Standish 2009 CHAOS Report

2009-04-30T10:53:00.001-05:00

http://www.standishgroup.com/newsroom/chaos_2009.php

Boston, Massachusetts, April 23, 2009 - New Standish Group report shows more project failing and less successful projects.

The Standish Group's just-released report, "CHAOS Summary 2009," "This year's results show a marked decrease in project success rates, with 32% of all projects succeeding which are delivered on time, on budget, with required features and functions" says Jim Johnson, chairman of The Standish Group, "44% were challenged which are late, over budget, and/or with less than the required features and functions and 24% failed which are cancelled prior to completion or delivered and never used."

"These numbers represent a downtick in the success rates from the previous study, as well as a significant increase in the number of failures", says Jim Crear, Standish Group CIO, "They are low point in the last five study periods. This year's results represent the highest failure rate in over a decade"

In the "CHAOS Summary 2009" report The Standish Group has re-examined 10 the CHAOS Success Factors. Each Success factor is supported by one of the Laws of CHAOS. The Standish Group's "CHAOS Summary 2009" report is available free of charge to Standish Group subscribers. Non-subscribers may obtain copies directly from The Standish Group for $99.00 per copy and the offer also includes Jim Johnson's book "My Life is Failure".

About The Standish Group International, Inc. Since 1985 The Standish Group, the leader in spotting future trends, has been helping end users and vendors of technology solutions prepare for the future. The Standish Group delivers fast, consistent and reliable IT advice built on a solid foundation of primary research. For further information on project studies and other trends, visit our website at: www.standishgroup.com.

FOR FURTHER INFORMATION CONTACT:
Jennifer Lynch
Communications Manager
Jennifer@standishgroup.com
508-760-3600 Ex: 22

2009-04-25T13:27:00.000-05:00

Project Management - The shortest distance between two points is a straight line

by Meade Rubenstein

Introduction
- This is my attempt at putting a book together on Project Management. Over the last few years I've focused on a website and blog hoping that would bring me fame and fortune. I'm not famous or rich, but what I did get out of it was a great sounding board for ideas which for the most part were no more then echos in a cave BUT every so often there came a response.
  This book is not intended just for people with a Project Manager title, but for anyone performing project management activities or wishing to. Project Management is a skill set utilized to mitigate risks. Project Management does not add value to a project, it prevents value from dissipating through unnecessary costs or loss of quality.
  I am a firm believer that:
  
  1. everyone is not suitable to be a project manager or fulfill project management responsibilities, it should not be considered a default position for those who are not good at coding
  
  2. the triple constraint, cost-scope-time, is wrong - there are additional variables such as quality and resources as well as project friction that need to be considered in managing projects. Someone, somewhere came up with the triple constraint triangle and for some reason this bad idea stuck. I feel the same way about Gantt charts, they might have been effective in the 1920's when they were invented, but times have changed and we need to work with real and detailed information not meaningless lines on a page.
  
  3. project management is really risk management.
  
  4. effective project management skills are required to be successful in any endeavor
  I hope this book provides some laughs and/or help, I will try to not write out of furstration of complete lack of knowledge.
Chapter 1 - A world without project managers
- Anytime you proactively adjust how you are working to ensure what you are working on gets done as effectively and efficiently as possible, you’re playing the role of a project manager.
  Project Management has been around since the cave man, the associated processes and tools have been utilized throughout time to accomplish objectives and delivery value. Until recently, project managers did not exist, but project management processes were used by anyone trying to accomplish something. PMI did not invent project management when it published the famous PMBOK (Project Management Book of Knowledge) book, it categorized a very limited set of processes that have been in use. Think (aka Initiate), Plan, Execute/Control and Close Out - the same steps cave men/women used to gather wood and cook a dyno-burger.
  1.1 Project Management activities
  - When you start a new job, you focus on where you’re sitting, who you’re working with, what your boss expects from you and how you can accomplish your job. The basics are: know where you are, know where you need to get to and develop a plan to accomplish that in the most effective and efficient way. These are the same steps every one follows in some manner.
    1.1.1 Know where you are
    - As odd as it may sound, this is an often overlooked step for project managers. You might start moving towards your destination, but without knowing where you are how can you determine the overall effort to get there OR even the feasibility of accomplishing the journey? Want to take a trip to Wyoming and don’t know what planet you’re on…good luck.
      What is there to know about where you are? And why is it important? If you want to make pancakes, you’ll need to know if you have pancake mix, what cooking skill level you have, if you have all the other ingredients, a pan, a stove, etc…many things we take for granted that end up causing us to deliver some pretty lousy pancakes. I recommend performing some level of evaluation on the following to determine where you are in general and then specific for a new project: Where you are – in General: 1. Historic information (aka corporate culture) in regards to: scope changes during projects, willingness to extend timelines, sensitivity to cost overruns, employee turnover rates, relationships with consultant agencies. 2. Technology strengths and weaknesses, including favored development environments, supported hardware, ability to grow/expand network and servers, network/server support levels and training availability. 3. Maturity/Level of all, including developers, QA, network/server administrators, database administrators, managers, etc. 4. Key business drivers, external influencers, related market trends, this information is used to determine potential external impacts/risks. 5. Current project management, software development life cycle (SDLC), QA processes including adherence to them and any planned changes. 6. Outcome of recently completed projects – the Good, Bad and Ugly of them. Where you are – specific to a new project: 1. Priority compared to other current projects. 2. Maturity/Level of all directly related people
    1.1.2 Know where you want to go
    - If you don’t know where you’re going you will either always be there or never be there. It’s not uncommon for projects to begin and work begin without anyone on the team OR the people providing the work to be completed to know where they’re going. There might be some general direction given or some foggy idea of what the goal is…but often time it’s not really known. Directions like:
      
      1. We need a website
      2. Management needs a dashboard
      3.Users are requesting a way to track orders
      
      May sound authoritative and firm, but are they really? Need a website to accomplish what? A dashboard for who? Why do users need to track their orders? When is any of this needed to be completed by and how much are you willing to spend to get it done? I’ve found that the traditional questions of: Who, What, Why, Where, When and How form a good foundation for determining the destination.
    1.1.3 Develop the plan to get you there
    - This is often the focus point of project managers, the development of the PLAN. When projects are failing, no matter the reason, management calls in the project managers looking for the PLAN and as everyone knows, no plan is complete without a Gantt chart. Plans are easy to create and even easier to present, the difficult part is creating a plan that has a high probability of succeeding and even more difficult is understanding the assumptions, constraints and risks associated with the plan. The ability to put a real plan in place, with clearly communicating all assumptions, constraints, quality levels, costs, risks, timelines, etc. separates a project manager from a PROJECT MANAGER. Don’t let anyone or any beautifully put together presentation fool you and lull you into believing that the path to success will be easy and painless. No one knows everything or has experienced everything, any project worth doing is usually so complex that once complete will provide another chapter in chaos theory.
      A solid plan needs to be molded to the people that you are working with, not only the developers, but also the sponsors, managers, users, 3rd party vendors, legal and anyone remotely involved in the project. Each team/person needs to understand their role, what’s expected of them and when.
  1.2 Project Management Processes
  - If you have any involvement in project management or IT you’ve probably heard of various project management/software development methodologies, including: SCRUM, eXtremeProgramming, Agile, CMM, waterfall, etc. Each methodology contains many interesting buzz words, various number of steps to success, never ending testimonials and detractors and no real proof of long term improvement. More seasoned project managers realize that there’s no silver bullet and will take what works, toss what doesn’t and continually review and adjust.
    1.2.1Processes for Knowing where you are
    - Most of the Processes for knowing Where You are will be adhoc communication ones. There are no set current processes that I know of to perform an evaluation of existing work environments. Proceed cautiously and inform everyone of your intent. The best way to capture this information is in spreadsheets, diagrams or (my favorite) MindMaps.
      Who:
      Develop an Organizational Chart (if there isn’t one already). Most companies will have some form of an organizational chart, this will be the foundation of this step. Use Visio or a MindMapping tool to create or re-enter the parts of the organizational chart relevant to you, providing as many layers that you will be in contact with. Include titles, contact information and any public relevant information. Be careful about your notes, don’t get personal.
      What:
      Processes - Document what current processes are in place and gather all relevant documentation about them. Talk to as many people as meaningful about them, especially those utilizing them, to determine actual use and value. You’re sure to get a lot of folklore thrown in. Technology – Document and inventory all used and supported technology, get an understanding of any planned or potential changes in direction internally and from the technology vendors. 3rd Parties and Service Level Agreements – Get a solid understanding of all 3rd party vendors and relationships, including those for training. Once again, work with as many people as possible and understand the short/long term agreements, historic working relationships, costs and SLA’s (service level agreements).
    1.2.2 Processes for Knowing where you want to go
    - Typically the project manager is not involved in the business aspects of knowing where the company wants to go, however there are various strains of goal and scope brain storming that project management skills could greatly assist. In recent times some formal processes have be implemented with some degrees of success, most notably Six Sigma which originated at Motorola (http://en.wikipedia.org/wiki/Six_Sigma). The most valuable component of where you are heading is the idea or need aka the Goal. Project management processes could greatly help in the validation of the benefit of the idea and the scope/boundaries of change. Many ideas are hatched, but few are truly evaluated and scoped to a degree they should be.
      The majority of New Ideas are not revolutionary thoughts, but additions to or improvements of existing products. The most beneficial ideas are those based on adding or creating new products, improvements or corrections to existing ones tend not to provide the same overall financial benefit since they are often costs savings that are difficult to qualify. There are many project management processes that help in the identification of the goal: For improvement projects – where the team is looking to improve upon existing tools and/or products you need to ensure that the groups is focused on the root cause issue and not a symptom. Root Cause Analysis (RCA) is a set of steps in helping define the true problem that you’re looking to resolve (http://en.wikipedia.org/wiki/Root_cause_analysis).
    1.2.3 Processes for the planning to get you there
    - This is where 99.999% of all project management is currently done, getting you there (wherever there is). While a very important aspect of the entire process, it tends to be the sole focus of project management and probably the root cause of why so many projects fail, basically the complete focus on getting somewhere…but I’ll cover my thoughts on this later. There are thousands of books, articles, discussion groups focused with this aspect of project management. Holy wars continue to be fought over methodologies, public executions occur daily and entire generations of peers disparaged. I’m a firm follower of the Agile Alliances’ Manifesto
      
      We are uncovering better ways of developing software by doing it and helping others do it.
      
      Through this work we have come to value:
      
      Individuals and interactions over processes and tools
      
      Working software over comprehensive documentation
      
      Customer collaboration over contract negotiation
      
      Responding to change over following a plan
      
      That is, while there is value in the items on the right, we value the items on the left more.
      
      (http://www.agilemanifesto.org/)
      
      When I first read it I knew I was delivered to a better place. How much clearer and precise could it be? Unfortunately, the dream has yet to be realized through any unified approach.
  1.3 Project Management Tools
  - 1.3.1 Tools to help you determine where you are
    - Knowing where you are is as difficult, if not significantly more difficult, then knowing where you want to go. You would think that you know where you are, but most people and companies don’t, this is because to do so you need to be very objective and willing to take a deep inflective look.
      Performing an inventory of processes, problems and organizational structure(s) would be a good start to understand where you are. The most important aspect is the listing of current problems, these can be obtained from your clients, help desk, Sr. Management and team ‘discussions’. Depending on what you company/your-team produces you might have many access points – or few – to reported problems. Depending on your situation, it might help to develop a questionnaire (have it approved and reviewed prior to sending out) that you can send to internal and external people. This information could be the input to a SWOT analysis Strengths/Weaknesses/Opportunities/Threats.
      Knowing where you are also means knowing what your strengths and capabilities are. Is your company/team very good at delivering short high quality websites, do you provide exceptional customer support, do you have a deep understanding of a specific business vertical? I’m a firm believer that by focusing on your strengths you will achieve more than working on your weak points. If you’re a fish focus on swimming. Make sure you capture this in your inventory/SWOT list.
      As far as actual tools to use, stick with Word (or OpenOffice) documents. Most of the information you gather will be very business sensitive, information that you would not typically want easily available via a wiki or web based document. A mindmapping tool would be good to use and highly recommended for all aspects of project management.
  - 1.3.2 Tools to help you know where you want to go
    - There are a few important tools to be used to determine where you/your-company/your-team wants to go. I highly recommend a mindmapping tool to fully define and scope the project. Understand the boundaries, the what’s-in/what’s-out list of items. The list should utilize terminology meaningful to the group defining the project. The confusion caused by the poor communication between the asker and the provider are probably the root cause for most project issues. I need a burger – ok, here’s a burger – well where’s the fries WHERE ARE THE FRIES EVERYONE KNOWS ALL BURGERS COME WITH FRIES, gee – sorry that’ll be a change request. Truly focus on communication early to ensure the correct scope is being captured, once again use: . mindmapping – to help gather the scope (aka Work Breakdown Structure – WBS) .cheap wireframes – I’ve found the only real use for PowerPoint is in easy/quick wireframe creation .role playing – if nothing else it’ll provide for some humor, capture it on video Many times the place you want to be is where your competitors are, so it always helps to provide links to their site and/or information to your team to provide for a better understanding.
  - 1.3.3 Tools to help you plan to get there

Chapter 2 - skills every project manager should have

Chapter 3 - where project management is heading

Interesting discussion on which type of project manager you would hire..

2009-04-23T08:06:00.001-05:00

Which Project Manager Would You Hire?

Posted by Pawel Brodzinski

The cold hard facts about Quality

2009-04-23T07:00:00.000-05:00

I’ve been involved in too many projects where quality is spoken about, tested for and held up high only to have it the first thing thrown out the door when delivery issues arise. It is often used as a reason for late delivery and a weapon to increase project costs. Let’s be upfront about a few things regarding quality:

Its more than functionality of the application
It’s much more then how the web page looks
It should not be determined by a designer or QA person alone
It’s not free OR cheap

Quality issues are always a symptom of the real problem, you can’t directly impact quality, but you can

increase/decrease design time
QA time/involvement
sponsor/user interviews and involvement
overall team quality (hire right, train and mentor)
ensure effective management (which impacts communication)

A good team is one that never discusses quality, because it’s a given that top quality will always be strived for.

Saying Thank You and Meaning Thank You

2009-04-22T07:00:00.001-05:00

I tend to have a bad habit of saying what I mean and another one of often saying thank you…I’m not sure if it’s old age (I feel old), appreciation of things (thanks Joseph Campbell) an appreciation of the comedy of life (thanks Bill Murray)…or what…but I truly appreciate when people make a good effort in what every they are doing and especially when it’s related to something that I’ve asked them to do. If someone really wanted to know what I think of as being a good quality of mine, this would be one of them. What bothers me, as you might guess, are people who either show no appreciation for other’s efforts OR provide superficial supporting comments/actions based on some evil management course. As managers, leaders, peers – we need to begin to truly emphasize and realize the efforts of others if we are to achieve anything more then superficial success. Sermon over for the day.

Top 10 Reasons Why Corporate IT Sucks via doodlekit

2009-04-17T16:19:00.001-05:00

via doodlekit

http://doodlekit.com/blog/entry/55860/top-10-reasons-why-corporate-it-sucks

don't forget to read the comments

When the bottleneck is you!

2009-04-15T07:00:00.000-05:00

Busy, more work than time in the day? Having to spend more and more time prioritizing to make sure the most important items get the focus? Worried that any more work and you’ll be in complete overload? Sit back, put your feet up and think for a moment….are these signs that you’re creating your own problems, that you’re placing yourself in the way of progress for your team and have made yourself into a bottleneck of progress? NO – you say…can’t be…I’m the most important cog in this machine and that’s why I’m so busy...take an outer body trip and look at yourself and your team, could it be:

Unwillingness to delegate (could be many reasons for this)
Your need for involvement in EVERYTHING as a form of job security
Inability to conclude/finish small/low-priority items to the level that they require (aka good enough)
Analysis Paralysis? Basic lack of knowing when enough is enough and willingness to take a calculated chance?

In most cases you CAN NOT correct the issue of being overworked by working harder, you cannot correct it by getting help (unless you are truly over worked and are willing to effectively delegate) AND you cannot correct the issue by looking outside of yourself. Sit back, be VERY objective and try something new.

simply inspiring

2009-04-09T18:28:00.002-05:00

What is an End Date?

2009-04-09T07:00:00.002-05:00

We all throw dates around like they have no real value. Open your project management tool, enter a task or bug, description, assign it to someone, set the start date and end date. How much consideration is put into the end date? How often to you actually reach the end date with the intended (big word) delivery? If anything we push the end date out as far as possible (especially if you’ve been around for more than a few days) – so far we often see our clients and managers get nose bleeds – to ensure that they can be achieved. It’s tough to admit, but I’ve gotten to a point where I treat end dates pretty badly, a commitment to an end date is like a commitment to the bar tender that this is my last beer…or close to the last one. If we don’t believe in end dates OR have faith that they are nothing more than the latest date people will accept OR know that 90% of the time they’ll move for 100 reasons we can come up with quickly in front of a board meeting THEN why do we think that ANYONE else will ever have real value in them? Pulling dates from the air is easy, living up to what we commit to is a bit more. As project managers we need to start realizing that the majority of the issues and negative feedback we face daily are ones that we cause and initiate ourselves…no wonder a recent report pointed to project managers as being one of the main sources of project failures – we’ve forgotten how to speak the truth and stand by the commitments we make OR ensure that ones we received are followed up on.

Programming Languages are the root cause of our issues – at least most of our issues

2009-04-03T07:00:00.000-05:00

Old firewood ovens have been replaced, refrigerators requiring large blocks of ice are now in museums and junk shops and old hand-churned approaches to mixing have been replaced a long time ago with the miracle of electricity….Progress is everywhere, Moore’s law speaks to hardware improvements….but what the heck happened to our programming languages? They’re frozen in time with no real significant change since the 1970’s (over 30 years ago)……how can you expect quality, performance and usability improvements when the basic building blocks are trapped in time when programmers were still living in caves? I’m sure you’re thinking about object oriented advances….well, hate to say it, for those few really using REAL object oriented coding, it hasn’t really solved much, basic bugging, recoding, lack of reuse, lack of patterns, lack of real error checking/trapping, lack of standards, lack of safety nets, etc. etc etc. are more prevalent than ever.

A telling sign that programming languages have not advanced much since the ‘70s is the continued high use of C – a pure, deep, solid – but OLD – programming language. (http://langpop.com/).

What we need is some real rethinking of how programming is done focusing on the current basic issues of buggy code, difficulty in deployment, team effort, etc…..I’ve seen a lot of people complaining, a lot of domain specific languages being created (which will add to the problem by having the same programming approach in various new domain specific languages) and NO real interest by any major IT organization or company in looking into establishing a new metaphor for programming….TIME TO WAKE UP AND DO SOMETHING……..

Your first date

2009-04-01T07:00:00.000-05:00

The most difficult of all dates is the first one – speaking project related here….it could come and go without even a notice, which is unfortunate because it’s typically a good reflection of how the rest of the project will proceed. Did you hit the date? If so, did you make it with achieving the full intent of the delivery? Did anyone applaud? Was the associated task meaningful and the delivery justifiable to the effort of tracking it? Don’t put to little of a meaning on the first project date, it could easily determine the long term relation if you’re objective and open enough to appreciate it.

Problem projects are the only ones worth managing

2009-03-28T07:00:00.000-05:00

It’s a simple truth, if a project will complete with no issues, then there’s no reason to manage it, conversely, only problematic projects are worth managing. Simple clear logic that is often ignored by everyone. It’s much easier seeing all projects as needing the same level of support and oversight….what would make sense, during the project initiation phase, is to determine the overall risk level of a project and set the project management support level required. This would reduce project costs and allow project managers to proactively focus on those projects deemed as high risk. As with anything else, a continued review and adjustment to the determination of risk level/pm involvement would need to take place.

Had my eyes open in the dark

2009-03-25T13:19:00.001-05:00

Tracking down root causes often reveals base, disturbing facts about our place in the corporate world. Project Managers are often working in the dark when it comes to real causes of delays and issues within any project….we are not given the insight to corporate wide decisions and political structures that are at the root of most project delays….I’m not talking about issues contained within a given project like missing tasks or poor processes, I’m talking about resource reassignment, uncooperative internal or external groups and funding changes. How often have you gotten push back or delayed response from a vendor, not because they’re incapable, but because they have not been paid for work to date? How many times when you’re looking for support from an internal group that you’re given the run-a-round, the real root cause being that the CEO has given conflicting goals/objectives to the various groups? We (project managers) often grasp at the most obvious cause to the problem and try to correct it, when in reality we’re chasing symptoms. We need to be more diligent, more willing to probe deeper, more willing to think before acting to really understand the root cause and be able to work within the given boundaries to correct. Act and don’t react. Know when then room is dark.

Irrelevance of project managers – we are not worthy

2009-03-24T07:00:00.000-05:00

Are we what we think we are OR what others perceive us to be? This is an age old question reaching far beyond project management – but one that everyone (even PMI certified project managers) need to ponder from time to time. Are we (project managers) truly irrelevant? Are we judged to harshly? In my opinion, I think we’re not judged harshly enough. I’ve seen many instances where project managers assume the role as messenger and judge their own value by how they manage the project as opposed to the actual outcome of the project. We put processes in place without really understanding the value of them or the potential negative impact. We don’t typically separate short from long term solutions and tend to resist getting deep into either the business or technology. We need to take more responsibility for the project outcome and assume a more proactive role in process improvement….we need develop true standards for project management and not rely on groups who sell certification to do so. It would be great to have a project management network with its focus on ‘open source’ training and self-policing certification instead of finding jobs and self promotion…

The great unknown

2009-03-21T07:00:00.000-05:00

I know I’m repeating myself when I say the #1 cause of project failure is the unknown – the unknown according to Capers Jones is missed requirements and missing design elements….this probably represents the majority of the unknowns. HOWEVER there are other unknowns lurking out there, ready to trip up even Sr. Project Managers….unknowns that could become knowns or better knowns if more time and effort is put forth…some key areas:

External impacts – this includes anything external to your groups and project. What if a 3rd party partner changes their API? The HR group decides to give everyone a 3 month longer vacation? IT becomes hot again and your people are stolen (for better salaries) from you?
Quality – what level quality of requirements and code are being delivered? To low and the end result will probably be shocking, to high and the cost/effort explodes past expectations.
Risks – was your risk analysis effective and provide adequate coverage? Did you include ALL the people you should have? You can only mitigate the risks you know and how good was the mitigation planning? Do they have gaps OR risks in themselves?
Productivity – how productive are the people on your team?
Technical limitations – can technology really address the problem at hand? Don’t be to confident, AI was suppose to be solved by now as well as having a moon colony….prototype and test the technology unknowns.
Expectations – do you really know the sponsors cost and timing expectations? Make sure that you’re both speaking the same language…what does complete really mean?

Ambushed!

2009-03-19T07:00:00.000-05:00

Happily walking to your meeting not expecting anything outside of some boredom and quality doodling time….then they strike! Ballistic questions, explosive statements and then the eerie quiet of a ruined career…there are some situations like this that you could never predict, but there are many that you can:

Holding information back or not proactively communicating – shame on you! You’re leaving the only avenue for people getting information from you in an open meeting where there’s no place to hide…like beating the bush to shake the tigers out, don’t get caught in a situation that you could have easily avoided.
Your project is missing delivery dates, once again openly communicate prior to the meeting and be prepared in the meeting to answer some tough questions. Open and honest communication is key - if you don’t know an answer say you’ll get back to them and DO SO…people’s confidence in you is only really tried in bad times.
Change of management? Expect anything and everything. It’s during shakeups that new management start asking some very pointed questions. A response of ‘that’s the way its always done’ may get you a trip to visit the prior managers on the unemployment line.
New peer? You may not be competitive, but your new neighbor might be. Time to keep your eyes open and realize the footsteps behind you may not be friendly ones. Do your job well, keep good notes, don’t slack and hope the person isn’t a direct relative to someone higher up…..
Office bully – there’s always someone that got beat up in grammar school and now its their time for revenge. A sharp comment, unfounded or not, needs to be addressed quickly and directly. Its an unfortunate fact of life that once a bully gets an upper hand, they tend to play it to the max. Be direct and devastating….if it’s an unfounded comment/question/remark say so loud and clear and then back it up with facts – time to take the gloves off.

Work is work is work – if you’re feeling comfortable and you’re not home with the doors locked and a cold beer in your hand…think again.

The wrong task for the right job

2009-03-16T14:34:00.000-05:00

A task as defined by Webster’s Dictionary (http://www.merriam-webster.com/dictionary/task) is a usually assigned piece of work to be finished in a certain time. What often happens in developing project plans is the ‘tossing’ of all potential, real and imagined tasks into a project management tool, many of which are:

non-conformable – you really can’t define what done means for this task
non-critical – the completion of the task is irrelevant to the success of the project
non-clusive. – does not fully define all the work required leaving additional work to be performed that is not tracked.

The biggest downside to ‘bad’ tasks are that they reduce the confidence level of the entire plan and in the project manager. Rule of thumb – back to Occam’s razor which I often refer to (correctly or otherwise) – track the minimal tasks required to ensure project success. A project’s worth is not in its thickness (as reference to college papers), but in its ability to help focus the team.

What do you learn from failing?

2009-03-14T07:00:00.002-05:00

Most times you learn to fail some more…you spend most of your time covering up the failure, justifying why you failed to yourself and looking for a new job…failure is a great kick in the ass, a humbling, leveling, humanizing experience AND if you’re mature enough (aka thick skinned) you can actually learn from it. Get a beer, cold cold beer, sit in a bar you never went to before and start to think very objectively what happened and why. If your thoughts go to those typical places like:

Not getting the backup/support needed
Other people sabotaged you
Everyone knew from the beginning that it would fail
Inability to control the unknown

STOP….that’s called the Blame Game…go back two steps, order another beer and try again. If you start to think about how you:

Could have been more proactive in communicating issues
Performed a better risk analysis
Better communicated current issues and potential impacts

Then you’re probably going in the right direction. Whatever the outcome of the failure (aka: out of work) the reflection is powerful, painful and a catalyst for growth.

(image via http://despair.com/)

Celebrity Apprentice

2009-03-11T15:29:00.002-05:00

As strange as it might sound, Celebrity Apprentice provides a great deal of insight into effective project management. Last week’s episode showed an interesting team dynamic basically pitting Scott Hamilton (Olympic skater) against Tom Green (Comedian). It doesn’t take a lot of time to see that there are to many ego’s in the room, but you can’t stop superstars from being superstars. What you (the project manager) should do is direct their talents and energies in directions that are mutually beneficial to all (including you). It also showed Scott making decisions without team consent, an important one that the entire team seemed to disapprove of….a project manager should contribute and direct but needs to ensure that they (we) are not overriding other considerations purely based on position. So, my list of learnings from this episode:

Top down planning – don’t focus on anyone area until the entire scope is known – otherwise how would you know what the critical path and/or most important delivery
Understand your team and use their strengths – assign tasks to the strongest team member in that area, ensure success
Timebox as needed – some decisions need to be made at a certain time if you’re going to hit the critical delivery dates
Don’t let personality issues get in the way – business is business, just because you don’t like someone (and for good reasons) doesn’t mean that they can’t contribute. Be open and honest – tell them they suck if you want, but listen to them for ideas and assign them tasks that they are capable and effective at.
Friendships sometimes get in the way…business IS business – decide if the friendship is worth your job and how much you’re willing to push that gray line…
You don’t always succeed, but you should never lose – things happen, understand what the potential outcomes are of a bad project and deal with them – pressure makes diamonds and a whole lot of coal.

http://www.nbc.com/the-celebrity-apprentice/

Beating a dead horse or being a dead horse

2009-02-19T22:41:00.002-05:00

Is there a finite amount of information that can be discussed, in an intelligible way, about project management – or for that case any technical subject (I’m not going to go beyond that). Let’s think of all the various project combinations, chaos points and potential external impact points….if it didn’t go on forever then how can there be new technologies and applications being developed?....all the new interesting personalities being introduced into the process….

The answer is that of course there’s a finite amount of project management information, project management doesn’t go on forever, what we see are just the various project management building blocks being arranged in different ways and being used in different projects by different people.

I remember reading Peopleware by DeMarco/Lister where, I think, in the first paragraph the discussion of how A/R systems are being programmed everyday, using the same A/R rules that have been in effect since the building of the great pyramids and how a large percent of those new systems fail for the same reason…and remembering how relevant it was since I was managing the development of a A/R system that was ‘having issues’. Isn’t this the same for project management, the same steps, ideas and approaches being used and reused since the first caveman project manager oversaw the first caveman IT project?

So, why is it that we continue to study, write and wonder about project management? Probably the same base reason we, as kids, put our fingers to close to the fire – because we really didn’t know it would hurt that bad….project management is about understanding how painful an experience it is to be part of a failed or failing project….the jerking back and wondering why it hurt and then figuring out how to make it not hurt again. We learn from ignoring past lessons, getting deep in trouble and then reinventing what those in the past have learned and tried to pass on. Overall a rambling but enlightening introspection.

The best way to catch a greased pig is have someone else chase it

2009-02-18T05:50:00.003-05:00

Waiting for an update from the development team on their progress? Need to get some key financial information from finance to Sr. management for approval? Wondering when a major release from another team is going live so you can coordinate your team’s activities? Calling HR for an update on the start date for a new hire? Feeling like a teenager again waiting by the phone for that special someone to call!

Many times project managers are put in position of trying to track down vital information from people who for many reasons are trying to avoid the disclosure of that information…come one now, you’ve been on the other side and know what it’s like to tell someone that the delivery is late…not a pleasant experience. The difficult part is that information gathering is a key part of our job, we can plan all day and night and color code those meaningless gantt charts until the MS Project Plan cow comes home, but without key current information, which our plans rely on we end up delivering fiction soon to be failure.

What can you do? Try harder? Yep, bang your head against the wall so at least you can show your boss the wounds you received trying to get the job done…and another reason why people will say that you try hard but are ineffective. How about strategizing a bit, getting into the other persons uncomfortable position and understand what would make them cough up the information – obviously your daily calls aren’t doing it. Try these approaches:

Tell them that you know they’re avoiding you and that you understand their pain and willing to buy them a beer….sometimes this works
Remind them that it’s their Sr. Managers who are asking you for the information and you’ll need to tell them where the delay is….(the ole’ turn up the heat on a dead crab routine)
Get close to their people, find out first hand (pre-spin) what the story is…ethical? Well….as ethical as delaying giving you the information.
Plan a meeting where you’ll be reviewing updates, include them and their managers and send out an email prior with a clear agenda (DAVE will be providing some news today…..) aka the Hot Seat
OR – perhaps the best approach – mention the request to their manager in a passing by, friendly, matter of fact, would you mind doing me a favor way….’Gee Sue, I haven’t seen Tom all day, would you mind telling him that I need to get his progress report….thanks…he’s a great person and I do hate interrupting him…but Mr. CEO is waiting for it’. Don’t accuse, don’t abuse, don’t plant negative seeds – just bump up the message – if the manager is a manager they’ll get the message that something is wrong and that you better get what you need so that the poop doesn’t flow up to their level.

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

2009-01-28T05:56:00.002-05:00

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

2009-01-21T20:46:00.002-05:00

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

2009-01-18T00:20:00.003-05:00

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

2009-01-18T00:16:00.002-05:00

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

2009-01-16T05:40:00.003-05:00

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.