Guiding Quote

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

Monday, July 21, 2014

Agile, Cabbages, and Cardiologists.


Apologies for the long interval between postings, at the end of May I went on vacation to Hawaii. Just at the end of the second week I became, in medical slang, a CABG, no not the vegetable, I was the recipient of a cardiac arterial bypass graft, three of them to be precise. Some end to a vacation!

One of the interesting events during my medical treatment occurred on the morning of the actual operation. I was literally wheeled into the operating theatre, moved to the operating table, surrounded by a surgical team all bustling about their duties when all of a sudden the cardiologist calls "Time Out". At which the entire surgical team paused and was asked to give details of what they knew about the operation and raised any questions they might have. So I knew that it was me they believed they where operating on and what they were going to do to me. So it was a "Scrum Meeting", Needless to say I was paying close attention to what everyone was saying. They even asked me if I had anything to say. Silently I hoped that they were all on their “A” game.

My second thought was that I can't get away from project management even in extremis!

Needless to say it was successful, so chalk it up to another success for Agile practices. 

Friday, May 23, 2014

The Project Manager as a Conductor



One of the favorite analogies in project management says that you can consider a project as a piece of music and the project team as a group of musicians: Band, Orchestra, Ensemble,etc. That makes the Project Manager the Conductor or Leader, the person responsible for making the group play and the music to flow. At it’s best the music is transcendent, at its worst it is a cacophony of discordant notes: Beethoven or Schoenberg, Teamwork or muddle. 

The important principle is that members of the group have to understand their role and the impact it has on the performance of the team. Critically the smaller the team the greater the impact of each role. A bum note in a sweeping orchestral movement will be lost, the same error in a string quartet is calamitous. However in a small group feedback on a performance is quick. The error and its creator are obvious to everyone, including them. In a large group then people can deny error and pass it off to another player. So the second violins as a section “carry the can” rather than an individual violinist.

Where the analogy breaks down is in the world of matrix management of resources. Imagine an orchestra in which every section is answerable to a different conductor as well as the person who is standing on the podium in the spotlight. And at random periods during the performance the section conductor is giving different advice on how to play the piece, or worse yanking the player off the stage to play for another group. 

Matrix management manifestly will not work for an orchestra, and it often doesn’t work for projects. Pity too many managements don’t realize that fact!

Sunday, May 11, 2014

Project management, software development, and executive management- an intellectual void




The software industry has been in existence for around 60 years. That was when the foundational ideas of Alan Turing and the genius of John von Neumann were turned into practical usage. Project management has been around for millennia, the Pyramids didn't build themselves. But in it's modern recognition as a separate profession it is also about the same age. Similarly modern business management became a teachable subject around the same time.

Yet the three practices do not co-exist in harmony. You would think that after all this time that they would have worked out how to relate to one another, understand each other's needs, and develop common series of practices: Construction has, movie production has, automobile manufacture has. Software? Not really.

Software has developed many astounding applications and enabled devices that where in the realm of SciFi a decade or so ago. Yet the number of projects, large and small, that fail is high. The UK has been trying to create an integrated system for it's healthcare system for decades. Best minds employed, big budgets, etc and it's been one failure after another.

You could argue that it is only the big complex systems that fail, but ask any internal IT department about the success rate of their projects and you'll get a deluge of horror stories. A lot of companies have trouble consistently delivering $50K projects on time and on budget.

Even if the project and software teams have a methodology they have a hard time of explaining their process to their business management. Software projects may be moving to a more flexible iterative process and yet their executive management is still wedded to point in time solutions. "How are you tracking to your milestones?", is a common question. Explanations of the new approach elicit nods of understanding, followed by a repeat of the same question.

Executives are not educated to handle uncertainty. They are trained to expect firm dates and to track to them. Their "profession" lacks the intellectual honesty to admit that they cannot predict outcomes. They expect, no demand, definite dates and expect everyone to stand by their initial estimates, no matter how circumstances change. They are in a state of intellectual denial, in an intellectual void.

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.