Guiding Quote

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

Sunday, March 30, 2014

Team Morale is Key

A key measure of a team’s health is the state of its morale. High performance groups typically show a good level of social cohesiveness and tolerance. It doesn’t mean that they are free from disagreement, what they are free from is acrimony. Constructive argument is good, destructive bickering is bad. So one of the tasks of any management is to maintain the morale of its workforce. 

At the project level it means constantly assessing the level of cooperation within the team. Low levels of cooperation are an indicator of poor teamwork and morale. It also involves making every member of your team feel that their contributions are essential and that they are regarded has valued members of it. 

The wide spread practice of forcing performance ratings that follow a normal distribution on a team is counter productive to maintaining good morale. It is hard to think of a more destructive action than forcing managers to rank their team within a prescriptive range. It doesn’t take long for people who have been designated as a poor performer to start acting like one.

Maintaining morale is a key management function, it cannot be delegated to some other body. One sign that a management team has run out of ideas is when they create a Morale Committee consisting of members of their workforce. Basically they are saying we know your morale is bad, so fix it! So if your company creates one then it’s time to reconsider your decision to stay there. Bad management cannot be fixed from within.

Tuesday, March 18, 2014

Software management: Waterfall, Agile, and Kuhn

In 1962 Thomas Kuhn wrote his renowned book 'The Structure of Scientific Revolutions' which among other things introduced us to the "paradigm shift", a hackneyed phrase much beloved by dull managements these days, but a significant new theme at the time. 

Also in the book was the concept that the adherents of the old way of looking at the world, the old paradigm, could not, with their previous training and experience, understand the new way of looking at the world. This inability to comprehend he termed as incommensurable, a clumsy word hardly surprising it lost out to paradigm. One of the books findings was that the adherents of the old paradigm are not so much converted to the new, but rather they are submerged by it. They and their views die out.

So what has this to do with software management? A great deal is the answer. Currently we have a major debate within the software project world about whether we should use waterfall or agile planning and development methods. Much ink has been spilt, and many strong positions taken. Definitely there is a great deal of incommensurabling going on and the triumph of one over the other is not on the horizon, far from it.

The problem for we project managers is that we are often called upon to bridge the gap. To be translators at best, peace makers at worst, between the disputing theologians. In addition we also have to communicate our schedules to senior managers who are steeped in the point value world. "Give me a date when this will finish and the next phase will start" is their usual response to scheduling questions. Iterative development with its vagaries and imprecision is a foreign land to them. Oh, they get the concepts of the method but they can't break free of the point value mind set.

I had an example recently on a database project I'm managing. We are using an iterative approach with scheduled releases of the database. The later releases will be more a case of fine tuning the model rather than major upgrades. The development, testing, and deployment will continue until the main program is completed. The applications that will use the database understand the approach and when they'll be able to use the new code for their development effort.

So far so good, the techies understand what's going on. Now we come to the incommensurable part, the executives managing the entire program. They want everything on one chart -as an aside I think PowerPoint has a lot to answer for in the ongoing process of dumbing down corporate executives - everything has to have discrete start and end dates that line up with dependent activities, they want waterfall.  After days of futile discussion, basically talking past each other, I gave them a waterfall version. As they say in the espionage world it was a convenient fiction, all that was missing was the traditional starting and finishing phrases of children's fairy tales. Whether they'll all live happily ever after is debatable, it is a software project after all.

The political learning point of this example is that you need to understand the requirements of all of your audiences and accommodate them as well as you can. Leave them comfortable with their illusions while you manage your project in the most effective manner: Duplicitous yes, politic absolutely!

Monday, March 10, 2014

Self sabotage and the OODA loop

I never underestimate the capability of executives to sabotage their own plans in the rush to meet some arbitrary financial target. Their inability to think holistically is systemic, if not genetic. If they used the OODA loop they might avoid it.

Two recent examples, one international in scope, the other more mundane, will illustrate the propensity to self harm. In the UK the leading supermarket chain declared a few years ago that it would use a profit margin of 5.6% as it's guide for all company planning and that it would coordinate all it's activities to maintain this high margin. The value was sacrosanct, had to be met, no matter what.

Well, why they were preoccupied with meeting and maintaining this target they took their collective eye off the market. In OODA terms they stopped observing. So when the market changed as the economic austerity caused by the Great Banker Cock Up of the mid 2000's made shoppers both more frugal and discerning they failed to orient to the new reality. Very difficult to re-orient the business if you don't pay attention to changing conditions because you are focused, anchored as it were, on a meaningless target. Like a sailor following the North Star and not looking out for reefs and rocks.
This fixation resulted in them losing market share to low cost provider at frugal end of their customer spectrum and to quality suppliers at the discerning end of their customers.

The second example is in the area of American cost cutting. In many companies the start of the new financial year heralds the season of the annual resource action - euphemism for job cuts. Well in this company the IT department was targeted for some blood letting. At the time they were in the midst of an internal audit, a big deal in their company. The auditors had stipulated that the department must use a specific tool to ensure uniformity of process, thereby making the auditors life easier.

So it was somewhat surprising, but knowing the managers not shocking, when they fired the only guys who knew how to use the tool. So the audit came to a screeching halt and a a panic of the "hair on fire" type ensued. Talk about not thinking things through, of not orienting correctly for the given situation. They could have kept the guys on until the audit was over, or kept one of them. Obviously no holistic thinking taking place. Totally fixated on reducing head count by a certain date and oblivious to the consequences.

In both cases lack of observing and orienting skills led to self sabotage. Bad enough when people are working against you, but it is really takes the biscuit when you do it to yourself. 

Tuesday, March 4, 2014

Interfaces and interlocks

Whenever a project relies upon other projects to provide key inputs, so called dependencies, the risk goes up. When the dependency is a clear one it is usually well managed. The dependent project has a very keen interest in it being so. But where the dependency is more opaque, or an interim solution is required, things can get overlooked or a complacent attitude prevails. In both cases the problems are discovered late and the dependent project is thrown into a panic.

I'm currently working on a project that is part of a much larger program, with numerous work streams involving infrastructure, networking, database design, and application development. One of the key activities involves transmitting a large amount of data for testing purposes from a mainframe site to server farm for database development, I'm managing the database part. The files are large and in production will be carried over a dedicated network. The network has been delayed and won't be available for the early part of the development effort. So an alternative transmission connection was required. This is when the chances of the wheels coming off started to increase, because once the network delay was identified and the question of transmission was raised the answer was; don't worry we'll move it using a virtual private network (VPN), no problem.

The moment this glib statement was made then this cynical PM immediately went on red alert. Why? Because passed experience with this company warned me that they were grossly underestimating the task and ignoring firewall permissions, server builds and authorities, and bandwidth. My tech team where equally blasé, relying on the fact that they had stipulated that they need the files by X date and that it was other peoples job to deliver them. I didn't share this sanguine attitude. I started badgering everyone in the whole transmission chain to give me the details of who was doing what, and when it would be done. Needless to say they all had other more pressing problems and without my push we'd never had made the date. Even so it was touch and go.

Interfaces between projects and programs are always a problem. You have to identify them, even if they are not obvious, then interlock with their managers, and constantly manage that interlock. People can forget their commitments: don't let them.