An Introductory Case Study

This partly imaginary case study shows what this book is about.

San joined the Navy from school. His parents could never have afforded a university course but he was a clever young man and was selected for officer training. Two years later he joined his first ship as a junior officer. He was an assistant communications officer. The first project the Captain gave him was rewriting the phone directory for the Model 600 telephone network aboard. He worked hard on this and using all his limited experience he produced an impressive booklet. It was an alphabetical list of crew members and each entry was cross-referenced with office or work space. He reported to the Captain ahead of schedule and presented his masterpiece. The Captain took one look at his offering, threw it overboard and sent him away.

Crestfallen San returned to the communications team. Here a wise old Petty Officer who had been with the Captain for years took him to one side. This is a warship, he explained. In combat, people die and things get blown up. The phone directory has to allow for this. San realized the error of his ways and returned to his work. Twenty-four hours later he returned to the Captain with his revised directory. This time it was organized by role, cross-referenced first by location and then by the names of those filling that role. If individuals were killed or injured and others took on their role, the book would still work. The Captain smiled. San had learned a good lesson as a Naval Officer and the ship had a new phone directory.

San served in the Navy for a further six years, both at sea and ashore in the main headquarters. He learned a great deal about people, particularly in the close confines of the ship, and when in the headquarters he learned the importance of understanding the politics surrounding issues. He left the Navy as it downsized and moved into project management. He worked on a variety of projects, from introducing traffic speeding cameras to building a new school. He became a Certified Associate in Project Management (CAPM) as soon as he could and built his qualifications in PRINCE2. After a few years he took the Project Management Professional (PMP) exam, passed and became a keen member of his country's chapter of the Project Management Institute (PMI). This personal development path not only built his qualifications but did so in line with his experience. It also afforded him a considerable support network of like-minded professionals. His experience continued to grow and, having completed a major project for an international communications company, he became an independent consultant. After some years he came back to the Defence Department as a contracted project manager on a major networking project for the Navy. His specific responsibility was the e-mail system.

He brought all his experience to this task. He made a point of getting to know all his team. He arranged social events and occasionally got them to bring their partners along. Long ago he'd learned the importance of a good memory and made a point of knowing something about all of them. He'd made it a personal rule to get round his team's office space each day and talk to as many as he could. He also arranged meetings with all the stakeholders he had identified and personally met with them all. Whilst he couldn't say he liked them all, he had at least created a relationship with them.

The project was a political minefield. There was much internal politics within the Defence Department and much interference from politicians. This was not surprising, since the project accounted for a large part of the defence budget. Moreover, the senior officers had had to be convinced that the system was worth it: couldn't the money be better spent just buying more weapons? Would the e-mail system really provide a better picture of what was going on in battle than the alternative, a networked system? Many senior officers were sceptical.

San was fortunate. He arrived at the project with a background in project management and an understanding of how the Navy worked at both the front line and in headquarters. He took several weeks before the project started to meet with a number of his old comrades to update himself on how things really were. He enjoyed being back in his old environment and this made him all the more determined to do a good job.

Once the project started he got into the detail of the specifications for the system he was to produce. As far as he could see, it was good. It had been developed using front-line users who would actually have to make it work at sea rather than in a test building. Remembering back to his first days at sea, he was pleased to note that it was role-based. The Captain's e-mail address would be '[Ship Name] Captain' rather than the name of the individual holding the post.

The software development for the whole project was run by a major international IT company. At the outset San was concerned. As normal, the IT company was trying hard to get the Navy to change its working practices to fit the software product, in order to minimize the number of modifications required. Often this causes no significant problems to the customer and helps by keeping costs down and resilience up, but San could see problems in this case because the proposed changes in working practices were not practicable in the environment of sea warfare.

As was his custom, San developed his reporting mechanisms with everyone in mind. He had learned over the years the advantages and disadvantages of various methods of communication, even learning sign language for one contract with a charity for children with impaired hearing. He did not waste time. His project support office worked extremely hard in the early days developing systems that would produce all the likely reports at the touch of a button, in a format appropriate to the recipient. He insisted that the database for his project was as open as possible to speed up reports. He prided himself on being able to produce reports rapidly on anything to do with the project. He regularly tested his staff with regular quizzes, on both project and general knowledge. His team began to enjoy his quizzes and became very competent with the reporting software as a result. These abilities proved their value when one day the head of the overall project, a difficult character and in a bad mood on that day, stormed into their office while San was away, demanding the most obscure of reports. The fact that the report was produced faster than he could drink a cup of coffee took him back a little and, despite his best efforts not to, he smiled.

All of these skills were of course why San had got the contract and he rapidly became well known in the Department as an individual who was at the top of his game and a good guy to work for.

Soon San realized that the scale and complexity of the project had been underestimated. The hardware element of the project was not going well. The network was to spread from the headquarters' offices to ships at sea. The hardware providers had assumed that running network cables through a warship was the same as doing so in an office block. The ramifications for the system of damage control procedures and airtight compartments for chemical environments had been missed. Most surprisingly, the IT supplier had forgotten that warships move around, sometimes violently, and when the ship moves so does the computer system. Hardware must be secured to the ship and not left on a desktop, and the system must cope with computers changing physical location as the ships move.

Such complexity was not the only problem. The software developers were having difficulty making the real-time data network operate at sea as it had in the lab. Every time they tried to add more than three ships the system crashed. This was a major problem, since the Navy's standard warfighting tactics required at least four vessels to be working together, which is what real-life experience and also computer modelling showed is the minimum effective force. Somewhat surprisingly, the chief programmer actually asked a senior Admiral if the Navy couldn't just make do with three ship formations. The Admiral's reply is unprintable.

Despite the problems on the horizon, San's project had been progressing well. He could do little about the infrastructure issues, but he was confident he would have the e-mail system ready on time. Then it all started to go wrong. He had taken his senior team members out for a coffee. Over coffee they told him that they thought the software provider was intending to use a name-based directory for the e-mail system, like the one that San had produced on his first ship and his Captain had thrown overboard. They knew this was a problem since at one of their first team meals San had told them the story of his first project. This problem had not been known until now because they were still using test addresses. San was worried. On his return to the office he contacted the relevant stakeholder and in conversation they confirmed his fears. It was the IT supplier's standard way of doing things and would therefore be much easier and cheaper to implement for them. 'Besides', he said, 'whoever wrote that element of the specification clearly didn't understand modern e-mail systems and was just copying the phone book. What difference could it make?' He added that the Defence Department had agreed to the specification.

San called a meeting with the software provider at which he explained in the greatest detail why role-based software was critical. This fell on deaf ears. The overall project already had enough problems and this wasn't going to be another. San pushed and pushed this issue for several weeks. At one point a Vice President of the software provider tried to hire him for another project at a much higher salary just to remove him as an obstacle to their plan. San turned this down but it did confirm that the issue was serious. San discovered that the individual who had agreed this in the Department was someone who had never served on a warship and knew little about the Navy. San returned to his office to think through how he would resolve this issue. He couldn't report a variation since the specification change had been agreed even though no one had informed him of the project support office. He decided to speak to the section head concerned. This got him no further since the section head took the view that San was creating yet another problem where one didn't exist. He couldn't even understand San's motivation, since sticking with a name-based system would enable the e-mail element to be completed even faster, earning them both a bonus.

San took the weekend to think this through. It was true he could be confident of a large bonus if he followed the name-based plan, but it troubled him deeply. Finally his wife asked him if he could live with either decision and he told her he could not. 'Decision made then', she said, 'go and see your old Captain and get some advice, this is all his fault anyway.'

The retired Admiral, as the Captain had become, was surprised to see San but pleased that the lesson taught years ago had not been forgotten. 'Leave it with me', he said, 'I might be retired but I think I can still pull a few strings.' True to his word, that's exactly what he did, so fast that even San was surprised. A directive came down from the head of the Navy three days later, stating that all communication systems were to be role-based. Unfortunately for San it was not too difficult for those involved to work out who had outmanoeuvred them. As a consequence his project came under close scrutiny. However, his team was a solid one as a result of all the activities they had done together and stuck by him when things became difficult.

San's battle was not a secret and he developed a reputation with the user community who reinforced his position at every possible occasion. After much argument at the highest levels, the IT company finally conceded and a role-based solution was accepted. San's team worked every hour available to implement it on schedule and they made it. Their rollout would be subject to the infrastructure delays but these had mostly been overcome. The great delay in the overall project was the data network. This team were still struggling with the complexity of what they were trying to create. The higher management of the Department were keen to demonstrate some progress, so San's system was rolled out as soon as the infrastructure was at an acceptable level. It was a great success and the lack of a data network to improve overall situational awareness was overcome aboard by using picture attachments on the e-mail system. It wasn't real time but it was a great step forward. And everyone was happy.

San was especially happy. He had the respect of those who mattered, even if he was not quite as rich as they and even if the software provider was never going to offer him employment. Then the situation in the country changed radically.

There had always been a separatist movement in the west of the country. The movement changed policy from demonstrations to armed insurrection. A civil war started. The west enlisted the help of a neighbouring country and its armed forces. San's country suffered many casualties. The conflict ended in victory for the government's forces, but in the aftermath it became all too clear that without the up-to-date picture of the battle that the improvised e-mail attachments provided, the government might well have lost the war. The IT company immediately laid claim to their brilliance in all the trade publications. However, a little-known retired Admiral wrote in the national press that had their original name-based solution been adopted, messages and orders would never have got through to the individuals who took over the roles of those lost in battle. The IT company lost credibility, and had anyway been involved in a number of major public procurement disasters. In his letter the Admiral accepted that theoretically high-tech forwarding and administrator actions could have solved the problem in an office of e-mail being addressed to a wounded or missing or dead officer, but he pointed out that in a fast-moving battle, people tend to die without forwarding their mail and administrative support can be far away.

San was vindicated. He is now working overseas on a desert pipeline project, and over a glass of lemonade in the evening wonders how he would have felt if he hadn't stood his ground all those years ago. He had learned a great deal over his career and it had all come together at the right time. Yes, he knew all the techniques of project management and kept up with developments, but it was his experience, ethics and desire to do more than just meet the specification that made him into the fine project manager that he is today.

Top of Page