Guiding Quote

“Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning.” Einstein

Sunday, June 24, 2012

Project Manager Types: The Attender


Some project manager’s believe that they should know everything that is happening on their project. That she should be able to give detailed answers to any and all questions. No matter how obscure. If she has this mindset then it naturally follows that she needs to be in every meeting, see every piece of paper, signs off on all requests.

She creates, unknowingly, a project bottleneck. Her need to know everything so she can answer all questions results in an ineffective project, because she must attend even the smallest meeting.

How do you know when you’ve met this type of manager? We’ll the fact that scheduling a meeting with them at short notice is very difficult is usually a clear indication. You usually hear her going through her calendar listing this detail meeting, and that detail meeting.

It’s not easy handling them, far from it. Their psychological need to be on top of everything is very strong. Probably they got burned on a previous project when they don’t have the requisite information for some detail orientated executive.

The best way at personal level is to counsel them to attend status meetings with subject matter experts and then progressively wean them off their dependence on knowing everything.

But, we are not therapists, we have projects to run. So, in the interest of our project we need to make sure that they realize that meetings with us, and the needs of our project are important and that they have to give us the appropriate priority. If they don’t then we have to escalate them to their managers. If there’s one thing that attenders hate it’s having to address questions from their managers in an uncontrolled manner. They want to control everything so threaten to break that control and you have the leverage to get what you need.

Sunday, June 17, 2012

Project Managers and Bosses - Hidden Agendas


Managers often say one thing when they really mean another, shock, horror!  Often the openly declared project objective disguises an underlying goal. The ostensible aim is one that can be agreed on by all, but it is really a stepping stone to another more controversial goal: A goal, which if it were to be openly declared, would raise a storm of objections against it.

During the Y2K scare I was involved with a major company with production sites around the global. Each of these sites had their own computer systems and supporting staff. The openly declared aim was to remediate all of these systems and also to update them to a new level of the common software. The hidden agenda was to consolidate the systems on a common server and then abolish all the local autonomy and departments. It would be centralization by stealth! The local sites would transmit their software for remediation to Y2K compliant code and when they expected the code to be returned they would find themselves subject to a switcheroo and centralization would have been achieved without any debate. Devious it was!  

It’s a prime example of an hidden agenda. Ultimately the plan failed because the local sites had been busy over the years amending their software to meet local needs and they had done a poor job of recording these changes. So the client couldn’t update to a new release of the software because of the cost of replicating the local changes, some of which were to meet local legal requirements and therefore had to be implemented.
            
A variation on the Hidden Agenda is the suspected hidden agenda. This is a more common occurrence and feeds into the paranoia and conspiracy theorists that abound in most corporations. Here the staff views the new project as a Trojan horse that will lead to changes that could be detrimental to their well being.
            
So how do we manage these situations? Well in the case of the hidden agenda it depends on whether or not you’re in on the deception. If you’re not in on the deception and you discover it, and it will have a detrimental effect, then the easiest way is to make the deception public. Hell hath no fury like those about to be conned! If the deal is not yet done then mere exposure will create such a furor that it may halt the entire process. If, on the other hand, the deed is almost completed then the row may result in concessions being made to the effected parties.
            
Now, if you’re in on the deception, shame on you, then you should be aware that if you are successful you will gain plaudits from your co-conspirators and the eternal mistrust of everyone else. No-one, I repeat, no-one, in your organization will trust you again, period. Every future project will run into blanket opposition and obstruction. No matter how hard you try, you will fail to convince anyone that this change is beneficial. In this organization you will be toast. Take the plaudits and move companies. You are done!

In the case of suspected hidden agendas all you can do is communicate regularly and show that the change is what you say it is and nothing more. However, be aware that one misstep or unintended consequence during the project can destroy all the good will you may have created previously. It’s a true saying that trust takes years to create and seconds to destroy.

Sunday, June 10, 2012

Project Managers and Methodologists - The Zealots


The joke goes, “Question: What’s the difference between a terrorist and a methodologist? Answer: You can negotiate with a terrorist!” Beware the methodologist and remember as far as they are concerned it never the methods fault, it’s your fault for using it incorrectly. Now before you get the wrong idea I’m not opposed to project and process methods. I sincerely believe they can be very beneficial. What I’m warning against is the inflexible application of methods in inappropriate situations.
There are two main groups that you need to deal with. The first one are the true believers - the Jihadists. 
These are the true believers in a method and they demand a pure implementation of its tenets no matter what it means in practical terms. So we get things like: Agile is the best and everyone must be co-located – even if half our team is in India, ISO9000 QA is essential so we must have a procedure for everything – including booking meeting rooms and ordering tea and biscuits for meetings, DOD specifications are paramount so a five man project lasting eight weeks has to follow its every stricture, the list goes on.

Zealots of any kind are dangerous and particularly so on projects. It’s their inability to compromise and address the practical issues in a flexible manner that is dangerous. It’s rare that you go for guidance on a method and come back with a quicker way of doing the job, one with less paper work to complete.

Plus methods, like religions have their various sects, the latest software method is called Agile. Within Agile you have: Scrum, Extreme Programming – XP, Unified Process, EVO. You have variations within sects, so you have Crystal Clear, Crystal Orange, Crystal Red and so on.

Now I do believe that Agile methods in certain circumstances are a real benefit. Just as I believe that Theory of Constraints principles are of value and good old waterfall processes have their place. They are all tools that have a place in project management. It’s all about using the right process for the task in hand

The problems arise when the methodologists insist one size fits all, and it’s their size, or you have conflicting methodologies in play at the same time. Currently in software development you have Waterfall and Agile slugging it out. We are experiencing as Kuhn would say, a “paradigm shift” from one way of doing things to another. And, also to use Kuhn again, the practitioners are talking past each other. Communication is poor to non-existent between the groups.

How do you manage this situation where you might have one part of you project being run by one set of methods and another part by another set and the output from one affects the other? If they are complete separate teams with no interaction then problem solved. They both stay on their relative islands and ignore each other.

Now I’m assuming that you’re an agnostic in this situation, basically you don’t care which method they use as long as it meets your schedule. Even if you do have strong views then the following advice will still be useful.

Firstly don’t try and force one group to adopt the other group’s methods. That is a sure recipe for chaos. If they have a proven way of working that delivers results let them use it. Don’t turn your project into a test bed for method re-education unless it’s unavoidable. Don’t try and get the adherents of the ‘new’ method to revert back to the old method. Team morale will plummet: people may leave the company.

You have to manage the interfaces between the teams and ensure that they communicate in a way that the other team can understand. Typically waterfall teams work on clearly defined product specifications, they expect signed off technical requirements documents as a given. Agile team’s work of a product function backlog and change specifications as the need arises. So there are genuine communication issues. Typically a Waterfall team supplying Agile team has less conceptual problems that an Agile team supplying a Waterfall team.  But they still have problems and you have to get the team leads together to determine how they will work together before commencing the work. You may have to knock heads together for the benefit of your project. You will be involved in ‘shuttle diplomacy’ between the teams and at some stage you may have to escalate the teams to their management if they refuse to play nice with each other. As I’ve mentioned before it’s all about managing the interfaces and the politics that are associated with them.

Tuesday, June 5, 2012

Project Manager Types - The Smoozer


The opposite of the compulsive  planner is the smoozer, a project manager who views their role has only talking with the client or working on the project team’s morale. For them creating a plan is a chore; working issues a drag; scope management a theoretical concept. With this type you have excellent customer satisfaction, for a while anyway, but you have no idea where the project’s going.

Usually moving this type of project manager is difficult, at least until the project goes pear shaped. What you do depends on the context in which you find yourself.

If they are on a project whose output is critical to your project then you have to demand regular detailed status reports and advise the client of the risks if the other project is late.

If they report to you then you can either force compliance with your project management system or, if the budget allows, you can support them with a good planner. 

If you work for them then recognize that you are going to have to step into the breach and the team is going to have to run the management system.