Project Management in Practice

Beyond the alphabet soup of PRINCE2, MSP, MoP, PMBOK, ITIL, Agile

Tag Archives: communication

Useful Project Management Presentations

In this post I have attached some presentations I have done over the years on project management and related topics. As I was looking at my SlideShare uploads, it occurred to me that these can be quite handy for others too. Hopefully it is of benefit to the readers of this blog.

This presentation is on the topic of managed services, presented at the International Esri Distributor Summit in San Diego, CA in July 2013.

The following presentations are two flavours, first one delivered to the PRINCE2 User Group in Wellington regarding benefits of using multiple ideas together. Second is a presentation to internal PMO regarding improvements to existing processes in project management.

The final presentation is one given at an IT conference in Wellington, New Zealand based on experience of enterprise software implementation at a major port in the west coast of the United States.

Enhanced by Zemanta

How do I manage during uncertainty?

If you are in New Zealand, you have probably had enough of the earthquakes. Difficulties Christchurch faced is known worldwide. In recent time my home city of Wellington has also suffered from a magnitude 6.5 earthquake followed by several aftershocks of over 5. Fortunately Wellington appears to have escaped reasonably lightly due to its rock base and higher standard of building code, due to its location on a known fault line.

How do I manage during uncertainty

I did a lot of consulting at the Canterbury Earthquake Recovery Authority (CERA) during its trying times. I saw a lot of their challenges first hand. What I had not experienced is the frazzled nerves. I always had the option of leaving, if the going got too tough. I have no such luxury in Wellington. Our office building has developed cracks in the stairwell, enough for management to be concerned about evacuating safely in the event of another emergency. We have decided to evacuate voluntarily until an independent engineering assessment is completed.

While that happens, we are in indefinite exile from the office. After the first earthquake some of the staff were locked out without access to their laptops. For an IT consultancy missing your laptop is like missing a limb. There is only so much you can do without it. We were back in the office for only a day before the continued aftershocks resulted in the evacuation. At least this time we had the opportunity for an orderly evacuation and took with us our laptops, notes, password stores, two factor authentication devices … basically things the team needs to do its work. Thankfully our document, work and incident management systems are all internet based.

The first lesson I have learned through this experience is about logistics. We have traditionally asked staff to turn off their laptops when leaving the office to save electricity. I have since asked my team to leave it plugged in and hibernation setting turned off or to take the laptop home. This to ensure in an unplanned office closure, we can be in a position to either provide them remote access to their laptop or they have it at their disposal.

We have dongles and other forms of access keys to connect to our customer environments to provide support. We are getting a second set of these from our customers and storing them at one of our other offices in a different city. When some of the team did not have access to their laptops, we switched our service model temporarily to provide advice and on-site consultancy. Many of our staff take their laptops home, so this was somewhat manageable. This approach does not always work. What is convenient to us is not always convenient for our customers, and you have to accept that.

The second and most important lesson I have learned is the value of co-location. I have stayed in touch with most of my team on a regular basis to provide direction, progress information and in general ensure well being of the team. What takes minimal time when you are together in the office takes significantly longer over the phone. Staff do appreciate being kept in touch. There is nothing like feeling left to fend for yourself to kill productivity. Lack of access to the regular work items will do enough of that.

I organised some localised meet ups to retain some level of camaraderie. Like other large cities, not everyone can make those at the same time with disruptions to public transport, lack of parking and access to central business district. Now that some of those challenges are abated, we are organising a room where staff can have meetings and drop in from time to time. What is lost in working on your own for prolonged periods is the ability to learn from each other.

While we had been working on a disaster resilience initiative, last fortnight has proved we are nowhere near there. It has been a challenging experience running a team size of ours remotely for extended periods. I have intentionally kept this post off the topic of financial impact and insurance, as my intention is to ponder the human elements in such situations. If you have experienced similar challenges and have found steps that work well, or does not work so well, I will be glad to hear.

As with what I saw in Christchurch, I am pleasantly surprised at the resilience of the team. Human beings have an amazing capacity to adapt to challenging situations.

Image Credit:

How much do you think it’ll cost?

How many times have you heard that? “Oh, I’m not going to hold you to this, but just a ball park figure?” Sounds even more familiar? And now the clincher, “You know our systems, surely you have an idea.” Trying to answer this sort of question from the client too soon causes enormous headaches in projects.

Cost is something that is never a black and white answer. Cost of the same project will differ markedly depending on what technology and process choices you make, what functional and non-functional standards you sign up to, how much of the subject matter expertise your clients are willing to provide to the project team and even some mundane things like what time of year you want the project to be implemented. A cost estimate therefore must accompany the scope, assumptions and conditions that it is based upon.

Many times you will have technical staff working with clients that will be put on the spot by these kinds of questions. They will have the best interest of the client and their own organisations by trying to answer the question. Unfortunately, this sets the expectation of cost from the client’s point of view. Some of the technical staff may be very skilled in their own responsibilities, but may lack the full project life cycle knowledge. Therefore the risk of underestimating or completely missing required activities is high.

In all likelihood the client has not had the time to frame what it is that they want. If they have a figure to go by, they will form the scope in due course and wrap that around the figure. This happens inevitably, even if there is significant gap between any cost figures you may have provided and when they had the time to form scope. There may not be any malice involved at all. This is how we as human beings operate – piece together bits of information to build the picture.

If you try to reset the expectations of the client at this point, it is tricky. There is always a chance to give the impression that now that they are interested, you are trying to squeeze them. Chance to set the correct expectation has long gone. By trying to be helpful, you have a situation on your hands.

You may come up with the same situation with your sales staff as well. They may be the ones that are responsible for communicating costs to your customers. Your challenges will be equally as pronounced if they miss the caveats. There is a fine balance between the cost appetite a customer has and the benefits they wish to gain from a project. In the quest of landing a sale you should not set a project up for failure. If the project is a keenly desired one for which your organisation is happy to make a loss on, then your management must be in a position to knowingly take the risk on. This should not come as a surprise during the project.

How can you go about ensuring the correct expectations at the outset? The first thing I make a policy on is to never provide estimates on the spot. I have only seen bad outcomes in trying to do that. Have standard estimating methodologies that you follow. The methodology may be different depending on the type of project you are managing – i.e. software development, construction, policy development etc. But there must be a methodology. Document the risks, assumptions and constraints that accompany the particular estimate. This way once the customer has had the time to think of the whole solution and the cost is different than the first one you provided, you can have an open and honest discussion on why that has transpired. This must extend to the whole team. Train them to tell the client that they will take the information back and follow up with an estimate.

First impressions do last long with customers – especially when costs and timelines are involved.

How does organisational growth impact project delivery?

Delivering projects is more than simply tasks undertaken to get something out of the door. Inevitably, how a project is delivered is dictated by the culture of the organisation. I work for a niche technology solution provider that has undergone nearly four-fold expansion since I joined six years ago. I have been thinking how that has changed our project delivery. Many of the analogies I draw will be familiar to you if you have read Frederick P Books Jr, the father of IBM System/360.

As a small company, we worked on small projects – mostly using one or two resources. Because of the size of work we could take in, there was a natural limit to risk we were exposed to. It is easy to communicate between two or three people by simply sitting next to each other. Even informal communication is sufficient to set goals, share designs, report progress and quality control each others’ work. Because the work packets are small, it is also easier to slot them in based on project timeline commitments. We managed to get a phenomenal productivity out of our staff.

As the company started growing, the work packets started getting larger. We were able to take on more complex work. Goals that a project manager could explain to two developers, now need considerable documentation. He cannot now sit next to all the team and fill in the gaps if something comes to light. As growth continued, there was need for more project managers. This creates more challenges, as now all the project managers have to align their processes to ensure projects are delivered in a uniform way. Slowly, but surely, the productivity achieved in the early days becomes difficult to sustain.

The staff we have are of exceptional calibre. So why the impact on productivity? The key here is the the overhead of communication. The original scenario I described is what Brooks calls the duo working out of a garage producing software that far exceeds big teams. However, there is a certain size of software you can produce with that capacity. In order to deliver something more complex with the two same developers, it will take so long it will not be worth pursuing. The only answer here is to add more people. As soon as you do that, it creates the productivity issues I talked about previously.

A simple mathematics shows the impact. The communication channels in your project team is n(n-1)/2. In a team of 2, there is only a single line of communication. Team of 3, makes it 3, 4 makes it 6. As you can see, More people you want to herd to the same goal, your communication effort multiplies exponentially. Military works by asking no questions. So one may ask why not follow that model. Most of your development team are usually from the opposite end of the IQ spectrum to that of your privates. Persuasion is your best ally here.

This clearly shows that more complex the delivery, and more people are required, software development itself becomes less of the overall effort. Ensuring the team works well, everyone knows what they are required to achieve, outputs are tested for their fit for purpose and efforts are targeted correctly to achieve the goal that has been set out requires considerable dedication.

Many a time reaction from management or clients is to throw more resource at it and expect output to increase in a linear fashion to the number of resources added. That may be achievable in fruit picking, or office cleaning, not in software development. It also does not take into account some tasks take a certain duration. No amount of resources will deliver an early output. I love Brooks’ analogy here … Bearing of a child takes nine months, no matter how many women are assigned.

Have you been growing recently? I would love to hear your experience.

How do I manage a distributed team?

As the world becomes smaller due to more efficient communication, distributed teams are becoming quite common. If you ring a customer service line in any country, the odds are you will end up being serviced by someone in Manila. Your latest Microsoft software was most likely developed in Bangalore. I have been managing projects with teams and clients  scattered in different parts of the country, and in some cases spanning multiple continents. I have been thinking about some of the challenges I face and how best to overcome them.

The biggest and most obvious challenge faced in managing distributed teams is the fact that you are not where they are. Even with all the new technologies, talking face to face remains the best form f communication. There are many forms of communications in projects – the truths, the half truths and the outright guesses. When you are managing the deliverables, you need to be on top of what is what. While this is not an insurmountable obstacle, it is a rather expensive one to mitigate. People work best with people they have known personally. They are more likely to be upfront with realities, than someone they find hard to relate with.

Working in different time zones also amplifies the problem. As an example, I work out of New Zealand and work with people in the west coast of the United States. During the southern hemisphere summer, it is reasonably workable, with abou 5 hours overlap. However, we lose a day. So we get about 20 hours during the week. In winter, during the Pacific Daylight Time, the overlap is as little as 12 hours. Our other base is in India, which starts work as we are leaving for the day.

Work cultures vary in different parts of the world. That plays a significant part in bringing a team together. New Zealand has a very relaxed working environment and an excellent work life balance. This is not to say, Kiwis are lazy by any nature. A lot of our innovation comes from this part of the world. I find Americans are much more intense with their work and put in significantly longer hours. Consequently there is always possibility of conflict if the teams perceive each other to be too pushy or too relaxed. Work cultures also vary in how people communicate bad news (or how they do not). While you do not want bad news in projects, if it does  pay to get it early.

If you are indeed managing people from all the different locations, the likelihood is you are not their direct line manager. They are each likely to have their own line managers to keep happy. This in itself is not uncommon in a project scenario. Temporary assignments from operational teams is a routine occurrence. It is quite different when you are not there to ensure the story you get is the reality, rather than the party line.

You can alter your usual working hours to accommodate additional collaboration between the teams. You can utilize advanced telecommunications to give a feeling of co-location and one team culture. These are all good measures, but intermediate ones. The more the teams are isolated, your picture will be less realistic and you will struggle to enforce uniform processes across the teams. The only way to bridge that gap is to ensure regular face time.

If it s important enough to have distributed teams, it is important enough to ensure effective management.

%d bloggers like this: