Problem Resolution or Project Resolution?

Several years ago a large government department IT section was in almost total stasis with every person desperately running in circles at 110% capacity every day but nothing could be accomplished.

Each person would come to work each day and arrive to problem after problem as management wanted this or that done urgently and a plethora of every day issues like simple user requests kept the IT staff occupied.

It wasn't until the end of the day came and the staff crept away for the night before they were called to another crisis, that they realized that yet again, nothing tangible was accomplished.

I was hired as the process and change consultant to come in and, along with other things, find a way to get things done.

I was there for a number of months trying to find a way around this issue. I had other work which kept me occupied as I oversaw a large project so I wasn't simply sitting in an office (sadly, I'd like one of those jobs sometime ... or maybe not).

At first I looked at the normal things like task management and priority and while this gave a little more clarity, it still didn't resolve the main problem of too few hours in the day. I looked at the logic of hiring more people but already this team was larger than most other IT departments for the size of the department.

I tried several other "normal" and quite logical practices but this government department were set in their ways of abusing the IT staff, and in turn the IT staff were too used to stamping fires.
I was reminded of a saying as I explained the issue to a colleague one time: "sometimes, when you're fighting back crocodiles, it's hard to remember that the purpose of the exercise is to drain the swamp".
It was then that I came up with a fairly drastic idea. I worked evenings and weekends over the next few weeks to fully document my plan. At last I took it to the executive for approval and was pleased to get an OK with their full support.

Over the next few months the IT department were able to implement several major installations and other changes. Yes there were still the same number of problems coming up each day but now, despite these every day issues, major projects were being completed.

What I proposed and implemented was nothing less than a total change in the structure of the IS department. Almost every person had a change in their title and job spec. It was drastic indeed but it worked.

I changed the title of the teams to ""xx Project Team", I changed the titles of the team leaders to "Project Managers", and the team members to "Project Support" or "Technical Project Support".
So why would changing someone's title make that much of a change to the way they work? As it turns out, there are several reasons. Firstly it gives them an amount of empowerment over their work. They now feel that they themselves can make decisions on how they prioritize their tasks.

Secondly they now have a focus. No longer are they coming to work to answer phone calls and being pushed and pulled in every direction. Their direction is clear - the project!

By changing their titles and focusing them on project work they can still "stamp fires" as they occur but now can choose which fires need their immediate attention and which can be left to another time while they concentrate on the all important project.

These people were well qualified and good at what they did, it was just that they had allowed themselves to be rag dolls being pushed and pulled from one event to another and it wasn't until now that they felt any sort of control at all. It didn't matter what a so called "expert" said to them or what procedures he wanted them to do, they never felt they had enough control over what they did to even attempt to follow them. By changing their focus to project work, I had given them that control.

So next time you and your team feel harasses and finding it difficult to get things done, ask yourself if you are out to resolve problems, or projects. Look at the longer term.

It has been said that there are two types of team leaders: one would take their team into the forest and by support, moral-boosting and excellent project control, would cut down the most trees in a day; the other would arrive at the location, then climb the tree to look around, come down and say "guys, we're in the wrong forest we'll need to move before we cut down any trees".

Think about it, plan, and know you're delivering to the correct goals.

Mind Mapping

I have been using mind mapping software for many years now and it has often been a great boost to get clarity around thought.
I know that I've often been told that my mind needs a map to get around and I've agreed with them. I know I  think the same way everyone else does. Do you memorize your phone number by turning it into a complex calculation? Of course you do and my wife's statements that I'm somehow different is just well, silly.
But back to mind maps.
I have a copy MindJet on my computer at home and pull it out occasionally to help me formulate some thoughts. Often this results in only a half a dozen links before I know where I'm going with my thoughts and can take it up from there. Sometimes it takes a very large map that I export to an outlined document where I can fully document the thoughts that are now concisely laid out before me.
However it wasn't until I started using mind mapping on my iPhone that real map production became a reality. Now I can take those ideas and problems that arise during the work day and map them out on the train ride home. Next morning I can export all of those linked thoughts into an outline document and produce my paper.
I've tried several systems on the iPhone from a straight outliner (CarbonFin Outliner) to specific mind mapping programs. There is no doubts on my favourite for the iPhone and that's MindNode. This is a simple clean interface that's good for all you can and need to do on an iPhone while sitting on a moving train. I love the fact that the points are not boxed (which to me, makes them harder to read) and each base node is a separate colour. I can even choose sub nodes to be different colours as well.
The ease of transferring the maps to my computer is as simple as selecting to email them (to myself) as an attachment. I have the choice then of several formats including graphics, as an outline document or one of a few standard formats other mind mapping software recognizes.
The only down side is that so far there is no way I can then copy maps back onto the iPhone unless I have an apple computer (which I don't). They say they are working on it and I hope so because this is a very powerful business function for the iPhone.
While I'm at it, why did I choose the iPhone? I've used the Psion, a PalmPilot, a Windows Mobile phone and the Blackberry. All work very well but I just like the simple nature and use I'd the iPhone. If I could I'd have perhaps gone with the Palm Pre but it is yet to be seen in Australia so I opted for the iPhone and so far, apart from the short battery time, quite enjoying it.

Cloud Computing

I went along to a cloud computing seminar last week to see what the fuss was all about.

Cloud computing is a term bandied about a lot in recent times and I really didn't fully understand what it was. When NetSuite put on a free seminar, that is to say; "a free sales pitch", I took the opportunity to go along and learn more about it.

I'm not putting down a supplier who would put on such a seminar, in fact I applaud it. It is a good way to learn the different technologies. However as in all such cases, we must weigh what we learn knowing that a fair bit of sales pitch comes along with the facts. This case was no exception to that rule.

So what's all the fuss about cloud computing? Well, it turns out not much at all … and a whole lot, it depends on your perspective.
Cloud computing is the name given to the industry springing up around hosting applications and data on the Internet (the cloud). The idea is that it allows a company to get away with just having the laptop or desktop PCs with no need for servers or the infrastructure normally required to support them. All email, scheduling, accounting and all other company software will be a matter of simply accessing the Internet.

Gmail is a good example of Cloud Computing where the small business can leave all their email details up to Gmail. No in house mail servers; everyone is automatically using the latest software; no backup issues; and no need for an administrator to keep it all protected and current.

The seminar hosted a few guest speakers who had moved all their corporate accounting to the Cloud (by sheer coincidence, NetSuite products - who would have known). It was interesting hearing first hand how they were able to make the change. I was especially interested to hear one company who had international offices and international currency issues and yet still made a successful change to Cloud Computing.

The only part of the evening that really annoyed me was hearing  Zach Nelson, CEO of NetSuite repeat often his favourite saying "why would anyone want to use applications designed before the Internet?". Zach repeated this several times and was obviously very proud of this saying but all it did for me was succeeded in getting my goat. Often applications are not built on the Cloud because of serious reasons. They may be very forward thinking applications that have some serious non-Internet uses. To me Zach Nelson's unfortunate comment displayed his ignorance of the wider business requirements and showed a very narrow view of the world. I will taper this a little though as his view as a Cloud Computing supplier with server based corporate software as his competition, he will naturally be narrow in his outlook.

There are no doubts in my mind that Cloud Computing will have a large future and it will be interesting to watch how fast the take-up will happen.

Sydney This Time

The photo was taken on my iPhone from our apartment towards the Blue Mountains one evening.

Here we go again. I'm really looking forward to buying a house and settling down in one place again. A luxury that has been out of our grasps for a while now.

After a great year in Melbourne we've moved again, this time to Sydney.

I've taken on a position as Product Manager for a spatial data (mapping) company in North Sydney. It's an interesting position and one that has enough challenges that will keep my interest and allow me to learn heaps. It is the first role I've takenon in many years that does not have a team, the last role had a team of around 40 people based all around the world so this will be a little different.

I'm looking into some exciting technologies and some interesting discussions which I hope to write about soon. The last year has been so disruptive that this blog has suffered from lack of postings, a situation that I hope to rectify in the coming months.

My interests reside in technologies that help companies and people, in leadership, and in company management so if you have something that you want me to look at, or simply want to meet up sometime and you live in Sydney, then drop me an email (from my profile section) and I'd love to talk to you.

Even Programmers need to Communicate

Few programming teams that I have met really understand how important communication is to their everyday lives. Let me yell this from the highest places I can find - Communication is the most important factor a software team can possess, above technical abilities, above delivery, above project work, above code itself. Without communication, a programming team can die.

Take two hypothetical programming teams, one is extremely effective and highly knowledgeable and technical. This team can deliver programs on time and on budget at every opportunity, have a repertoire of current programming languages and skills, and can understand and deliver highly complex applications. However, this team has no communication skills.

The second team has only ever used a single 4GL language, have no technical knowledge outside of their areas and couldn’t hit a delivery target if it was painted on the side of a building in big bold bright neon colours. This team however works hard at communication.

Now let’s put this in terms understood in today’s financial restraints – Which team would be open to being outsourced?

The answer would be the first team. Without communication, this team are “perceived” by management and other departments as a cost to the company and full of Prima Donna programmers who don’t offer any service to the company to justify their (perception) huge salaries.

The second group however are perceived by management as a hard working and loyal group of technically brilliant people that the company simply cannot do without.

Development teams must be able to explain what they are doing, why they are doing it, the value they give to the company, and why that value should be maintained. But we are talking about a bunch of programmers here. By pure definition these people communicate with one’s and zero’s not with other living organisms.

I’ll draw on my own experience to give you a real life example of the changes that communication can give to a programming team.

Many years ago, I was appointed as development Manager to a team of programmers. During the interview process, this team had been described to me as unable to achieve any targets. Production was down and the team was not viewed as a valued asset to the company. It was generally accepted that the team would be outsourced within the next 6 months and I would then move into IT Manager’s role (due to be vacated).

The first few days on the job, I observed what was happening. Every 30 minutes or so, a different department manager would come into the development area and talk directly to one of the developers and demand they drop what they were doing and work on their project as it was needed yesterday. The programmer would dutifully drop their current workload and take up the task demanded of him by that manager.

No wonder the programmers had a bad name - they could never finish anything because they were constantly being shifted to working on something else. Every manager thought the programmers had to be forced to work on their material otherwise they’d never get their project out.

The programmers also complained about their workload telling me they needed to at least double the team to keep up with their work.

I looked at the code and the projects these developers worked on and spoke to them about their work. It quickly became apparent that the skill level was extremely high but the moral was at an all time low. I concluded that their only fault was their communication so I set about correcting this and became the mouthpiece of the Development Team.

There were several things I did immediately which had a huge impact. The first was to put into place a job request form. This was originally a simple paper based form allowing users to enter the details of their project on a paper that had a unique job number. This job number was kept by the internal customer to refer to their request.

For the first time, programmers were then able to prioritise their work. They were also able to see what work was ahead of them. By having all their work available on the desk in front of them, they could tell the internal customer that their job would be due to be completed at a particular date.

I also spoke individually to those customers who filled out the form, explaining the work request form giving them confidence that their project was now in the “system” and that the work was now prioritised and a date for delivery was now available. This meant that customers were much less likely to come in and speak directly to the programmer unless their project was late.

Meaning the programmer could concentrate on completing that one task without interruption - new requests could be referred to the job request and any member of the team could take over this discussion. Jobs were actually getting completed.

Now we had the process in place, I concentrated on communication. It was then my job to support the team by educating everyone on this new process and how to use it to their advantage. I wrote up a development process document and created one-on-one meetings with each of the departmental managers throughout the company. There I showed them through the process and effectively “Sold” the process to them. I also added a “Software Development” column to the company fortnightly newsletter and added the Software Development department to the list of those giving a talk to new employees during their induction. This had the added side effect of being seen by other managers who came along to the induction process for their talk.

I then started talking directly to the CEO (Chief Executive Officer). I told him what was happening to the Software Development Department and what applications we built and look after in his organisation.

Within six months, this department went from being a bunch of dead-beats who were due to be outsourced, to being the only IT department that was confirmed too valuable to be outsourced. The CEO started placing Software Development on his rounds when showing visiting VIPs through the company and the main software packages we wrote and supported were being highlighted as great achievements for the company. Eventually the CEO, in his monthly report, stated that all of the company should look towards the Software Development Department as an example of what a well run department should look like.

So for the matter of a few processes and some effective COMMUNICATION, this team went from a dead weight and an unwanted “cost” to the company, to taking pride of place within the corporate environment.

So yes, even programmers need communication. Few programmers have that ability to communicate effectively. That is their nature in that the skills of a really good developer are in understanding code and code flow, and to understanding the user’s requirements and delivering to them, not in the areas of marketing and communication. It is up to those supporting the team - the Development Manager, the Team Leader, or the Project Manager - to take up this task of communication.