Cutting Out Delays caused by Customers

Cutting Out Delays caused by Customers

Your project will not be delivered on time and to budget if you are not successful in cutting out delays caused by customers.

The biggest suppliers to the project are usually the internal or external customers of the project. It is a lot easier to manage suppliers to the project who are not customers. It is a lot harder to manage customers or users when they are in the role of supplier. They provide information at all stages, sign-off, facilities, test data etc.

When they deliver something late, e.g. information, it is difficult to report them to their superiors without causing friction. Any delay to the project caused by them will not be reported as such. It will be put down to you. You, therefore, had better fix it.

Crucial Mechanism

It is important to put a mechanism in place at the start of the project which ensures that any late supplying of information etc. is documented and automatically escalated. There should be a written agreement with the senior project sponsor or senior customer, i.e. whoever is ordering the software product. The project sponsor is usually happy to do this as they do not want delays to the project, with the resulting cost increases.

When a delay is caused to the project by any supplier, including the customer, a Delay Note should be issued. This delay note should document the cost in terms of scheduled days, elapsed time and money. This should be given to a senior IT person, perhaps the head of IT or of software development to be passed on to the project sponsor.

Automatic Escalation

This escalation process should be automatic so that the person who escalates it can say to their customer contact that it is part of the process. If the project is being done for an external customer, the costs of the delay should be passed on to them. This should be stated in the initial contract.

What will happen, usually, in practice, is that the customers or business users that you are liaising with will not take this seriously at first. They’ll have other priorities. They would see the current business as being more important than a system they’ll get down the line.

They don’t think you’ll report them. They don’t think you’ve got the balls to do it. They don’t think you’ll  jeopardise your relationship with them by reporting them to their boss. Therefore you must do it. The sooner you do it on the project the better – and do it to someone that the other users didn’t think you would do it do. They must think ‘if he does it to them he could do it to me’.

Stamping Authority

It’s a bit like a referee stamping his authority on a game early on to show he means business and will not take any malarkey.

I did it on one project to my opposite number, a guy called Frederik. He was the Project manager on the customer side and I was the Project Manager on the supplier side. We each had only one person above us on the project. I reported to the MD on the project and Frederik reported to the project sponsor on the customer side.

It had been pointed out to me by the software Project Manager that, although Frederik was always very insistent that we had got everything done, he often didn’t have what he was supposed to do done. This may have been the supply of information or the supply of good test data. No one had ever called him up on it before. He was the customer after all.

Good Relationship

I had a very good relationship with Frederik. We got on well and we saw most things the same way.

So, the first meeting after it had been pointed out to me that he often didn’t deliver I said at the start of the meeting that every time someone (anyone) hadn’t delivered something that they should have done at the meeting I was going to start a game of hangman for them.

Gradually the gallows were constructed line-by-line and Frederik eventually ‘hanged’. I hadn’t set it out specifically for Frederik (or so he thought). It was for everyone. His lieutenants on the project could see it and our people could see it. He was the main non-deliverer.

Good Spirit

He took it in good spirit and I was hoping that he would see the light and change his behaviour without my having to report him. He did improve for a while but then he started to deteriorate again – and it was something major. His lack of delivery on it would be a major impact on our being able to deliver the project on time. From memory I think it was the supply of test data. His would hold the whole project up.

I knew I had to act. I issued a Project Delay Note and gave it to my boss the MD. He contacted the Project Sponsor on the customer side without delay. It was Friday afternoon.

Bad Weekend

On Monday morning I was told that Frederik was trying to get hold of me. I thought I’d let him stew for a while. I waited till the afternoon to get in touch.

“I’ve had a very, very bad weekend” he said in what sounded like menacing tones. “Was it raining in Holland then?“ I asked him. “It was nothing to do with the weather” he replied. “I think you know what I’m talking about. You should have had the courtesy to come to me first”.

It seemed that his bad weekend had been caused by an almighty dressing down by a very angry Project Sponsor on the customer side, i.e. his boss on the project.

Automatic Escalation

“I was forced to do it”, I said. It was part of the procedures that you signed off on. If I didn’t do it I would have been in trouble myself if I hadn’t”.

He said “You should still have come to me first”.

I told him that I had tried other methods like the hangman. However, he still hadn’t got the message. “This was a last resort for me” I said. I think grudgingly he accepted it. However, what was more important was that his behaviour changed. He didn’t want any more bad weekends.

Be Brave

It was an uncomfortable phone call. However, you have to be brave. The rewards are very high for doing it. Can you imagine a project where the customers or users deliver everything they should on time? What a bonus this would be to your ability to deliver the project on time and to budget.

And yes, this is what happened. There were no future major delays to the project. This was a highly significant factor in our bringing in the project ahead of schedule and making a good profit which impacted very significantly on the careers of the MD and of myself.

You must also keep a wary eye out for those that work on the project for you and make sure they escalate to you any problems that they are having with their opposite numbers and their deliveries to them. If you find out that they are not escalating delays to you then you should let them know in no uncertain terms that this is not acceptable.

Zero Tolerance

There should be zero tolerance on this. The people most likely to screw up the project for you in terms of getting it done on time and to budget (and making a healthy profit) are the customers themselves. Don’t let them do it. It’s an absolute certainty that they’ll try. Impress on your people how important it is to stop them doing so. Impress on them, also, that it will be a very grave misdemeanour if your people let their opposite numbers away with this without escalating it to you. It simply won’t be tolerated.

Productivity through Motivation on a Software Project

Productivity through Motivation

One of the greatest gains you can make on a software project is better productivity through motivation.

The great American Football coach, Vince Lombardi, once said that there are a lot of coaches who can improve the team tactically but that the really successful ones are those that can get “inside those guys’ heads and bring the best out of them”.

I have asked many people who work as developers in the industry how much more productive they could be if they were really motivated. Most of these have many years of experience. The answers they give me are usually in the range of being 50% to 200% more productive. I won’t name them here. When asked what would motivate them to achieve these greater rates of productivity they usually answer that if they were working for themselves they could achieve those levels.

Doubly Productive

It is very interesting to note that your project members could be, on average, doubly productive if truly motivated. Maybe they will never give you the same productivity that they would give themselves. You should be able to unlock some of these productivity gains if you simulate, as far as possible, working for themselves.

Conditions in which they profit (and profit well) from their productivity gains should be created. The model of the City of London traders should be used. They are trained well, given a base salary, motivated by a sharing of rewards, and set free to make money for their companies and for themselves.

Best Developers

By doing something similar, it would be easier to keep your best developers and to stop them going freelance. By giving them a base salary and a pension you give them security. By giving them a chance to earn large bonuses by bringing in projects, and their parts of the project, ahead of budget and schedule, you give them the chance to make money.

With this mixture of security and earning potential, and possibly career progression as well, why would anyone want to leave to become freelance? Why, indeed, would they want take another permanent job with another company which has backward practices, low rewards, and fewer opportunities to achieve and be recognised.

Imagine All Your People

Imagine a company where the people are highly motivated, have security, are well rewarded, and have high self esteem through high (and constantly improving) productivity. This company will retain its best people and their business knowledge. It will produce software of better quality and with better time-to-market than its competitors.

People’s morale will be high. Customers will be highly satisfied. They will gain market share and have high margins. The Finance Director will smile. The shareholders will be rich. They will reward their senior management. This company will be a worldbeater. There’s absolutely no reason why this company could not be yours.

It is not easy. Any change is resisted. To be forewarned, however, is to be forearmed

Keeping Your Best People – The Winter Holocaust

Keeping Your Best People – The Winter Holocaust

Keeping your best people is one of the major factors to success.

At a company where I was Chief Information Officer we used to hold People Satisfaction Surveys based on categories like career prospects, remuneration, management, the working environment etc. We held these every three months, in January, April, July, and October. One thing that we found was that morale was seasonally affected.

Morale was highest in October, dipping in January, hitting its bottom in April after a long hard winter and picking up again in July. We also found that the People Satisfaction Survey was a good leading indicator (by about 2-3 months) for staff attrition. When people are feeling at their lowest, they send out their CVs.

Lower Morale

During the winter people come to work in the dark and leave in the dark. It is not just this factor, though, that causes lower people morale. More projects are implemented in the winter (January 1st being a favourite implementation date). Because of staff holidays fewer projects are implemented in summer.

Therefore, people are working longer and harder in the winter on projects which are probably failing without much thanks or encouragement from management. While people are working, vis inertia kicks in and they don’t find time to compile their CVs. It’s only when they have a few days away like at Christmas, Easter or one of the spring bank holidays that they start to assess whether it is worth it. Many decide it isn’t.

Social Activities

To be forewarned is to be forearmed. The dark days of January, February and March are the time when social activities should be organised. At this company, we used to always hold the Software Academy Awards in February. There were various awards like best manager, best developer, best business analyst etc.

Everyone in the IT department voted for these categories. An awards evening was organised, with most of the expense being met by the sports and social club. Senior management were invited. Presentations, in reverse order, were made to the top three in each category. Each of the first three received a certificate.

Winners

The winners received fifty pounds in the serious categories and a bottle of champagne in the joke categories. It was organised by the people for the people. It engendered much interest in the two weeks before and for a few days afterwards The fact that the award was given by their peers, and that the handing over of the award was witnessed by senior management, was important.

This one event won’t sustain morale throughout the whole winter but it will contribute to it. I’ve often thought of having another awards night with the awards being decided by management. This, however, is fraught with danger. As it is outside work hours, will people turn up to see what may be perceived as ‘management lackeys’ receive their awards?

Pay Rises

This time of the year is probably a good time of the year to give out pay rises and promotions. At the very least it will narrow the differential between what you are paying and what they could receive in the marketplace. Once the CVs are sent out you are probably too late. When the staff agencies are sweet talking your people, and other companies are keen to have them, the grass seems an awful lot greener on the other side.

It’s counterproductive to try to keep them once they’ve resigned. They usually refuse but tell the rest of your people that you’ve made the offer. It becomes the perceived wisdom among the remaining people that the only way to get ahead in the company is to resign. This is not good for morale.

When people do resign, companies usually either try to make them work their full notice period (being crucial to the project) or they have them out the door that day (sometimes supervised by the security guard and marched out the door). The first is not clever. People who are going are not motivated to work. They usually spend the time de-motivating other people. It is usually people who are close to them who are next to leave the company.

Too Harsh

The second way is too harsh. They have friends and colleagues who remain at the company. People will not appreciate one of their members who have given good service to the company being ceremoniously or unceremoniously ejected. They will feel that the company does not appreciate good service.

It is better, and gentler, to give them a couple of days to pass their work over to someone else. You are going to lose them anyway. You might as well get used to it. A couple of days is also not enough for them to seriously disaffect the other members of staff. They are usually in the first flush after their resignation and feeling kindly towards their old company. Thank them, at their leaving speech, for all the good work they’ve done for the company and wish them well in their new job. This is relatively painless and everyone is reasonably happy.

Learning from Mistakes

Learning from Mistakes

One of the axe-sharpening activities for which there is seldom time is the activity concerned with understanding why mistakes were made and crushing them out of the process so that they do not occur again. One of the reasons why these activities are not usually allowed is that the time they take is not usually in the schedule and because many of the benefits are for future projects.

This can be cured in several ways. In the beginning do not attempt too much. Preventing defects, like politics is the art of the possible. Prevention of Defect meetings should happen, during projects, only when sub-systems are delivered into test, not when individual programmes are delivered. They should only analyse higher category defects. At one organisation, they had nine categories of defects of which they analysed only the top five categories.

The Lesson Learning meetings should last only an hour. There are two purposes for the meetings. The first is to ensure that the person who created the defects understands why they happened. If they take time out to understand why they created the defects they are less likely to create them again. This activity happens in other professions.

Football Clubs

At football clubs they use video evidence on a Monday morning to analyse the problems that occurred in the match at the weekend. The players are then able to analyse and visualise what they should have done. It breeds good habits. When Liverpool were the top team in the country, whenever a player was transferred from them to another club, the manager of the new club would always try to find out from the player what the Liverpool secret was.

But there was no secret. As Bill Shankly said, they hired the best people and did the simple things. They didn’t do things like pass the ball across their own area. They had cut out all the mistakes which had caused them problems in the past. This was good people with good processes.

Mistake Analysis

The second purpose is to allow the analysis of these mistakes so that the process can be changed to prevent the mistakes happening again. In the past I have found that many of these problems occur because of misunderstandings at various stages. Very often this analysis leads to elements of Rapid Application Development (RAD), especially Joint Application Development (JAD) being taken into the process and the use of developers rather than analysts, designers and programmers. The fewer handovers, the fewer misunderstandings there are.

Standard Practice

Fortune magazine once analysed the software practices of the top 500 companies in the USA. They found that there were four main practices which separated the best performing software departments from the worst. These were:-

o             Standardisation – of platforms, methods, models etc.

o             Joint Application Development (JAD)

o             Timeboxing

o             Prototyping

You may short circuit many of your defects by implementing these best practices.

You should analyse your mistakes so that you are constantly learning from this mistakes and getting better and more productive as an organisation.