Project Management in Practice

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

Tag Archives: Management

Is productivity gains the answer to improved business outcome?


Is productivity gains the answer to improved business outcomeI recently ran into an old school friend. At the time we were nearing the end of high school he was the coolest dude with a job at a fast food place. He had disposable income and an old second hand car. What else do you need in life? Those of us that were planning further studies or apprenticeships got plenty of advice from him on the futility of our endeavours. When someone mentioned better prospects and better pay, he simply said if he ever needed more money he can simply work a few extra hours.

All these years later I was surprised to see him holding training materials. I was intrigued with this change of attitude. At the time some of us were thinking of investing in our future and as a result consciously taking on a few more  years of hardship, he had no appreciation that his circumstances could change. He shared with me his predicament in working harder and harder to support his family. This larger than life character was backed into a corner. It is great to see him sorting his life out.

What has this got to do with business outcomes you may ask? It occurred to me how many organisations take a similar approach to making money. Everyone is in a mad rush to squeeze yet another billable hour out of staff, minimise non-utilised time. The only certainty is that the environments we operate in will change. As my friend found out eventually, there is only so much difference you can make using this approach.

True sustainable change comes when you have the commitment to review your methods, acknowledge the failings and change accordingly.

Image Credit: under30ceo.com

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: Stuff.co.nz

5 things to do when projects go wrong


5-things-to-do-when-projects-go-wrongAnyone spending a decent amount of time in project management field will sometimes have projects from time to time that experience significant difficulties. For all the planning, it is never possible to predict all the eventualities and therefore foreseeing all risks. Projects are by nature more risky than other business activities. It is always useful to apply a few techniques to aid in such situations.

1. Show leadership

An oft repeated cliché this is something that is hard to explain in terms of action. When things go wrong there is plenty of nerves in the project team and management. Project team members often struggle to think beyond their immediate problem. You will find internal executives or sponsors worrying about contractual obligations and any fallout with the customer. Showing leadership in this context is to ensure this uncertainty does not spread into panic. The role of the project manager is to steer a clear course and stopping any blame game that may raise its ugly head. Now is not the time for that. Focus on why after the project.

2. Avoid temptation to simply throw more resource

A common reaction to a struggling project is to throw more resources at it. If the project is of high visibility and management is not able to provide subject matter expertise, they will feel they need to contribute somehow to correct it. The commodity at their disposal is resources. Be wary of this. More cooks do not equate to a better dish. You may need to enlist some mentoring for project team members or even yourself if you are managing a project outside of your technical expertise. Always consider how much time it will take before new resources can contribute to the project. If the issue is time, you will virtually ensure a delayed delivery by adding resources. Also take into account the additional communication required to successfully integrate them.

3. Avoid sugar coating

There is a temptation to play things down as things start going wrong to avoid creating panic. I have found it easier to be transparent about progress. Late surprises will compromise integrity of the project like no other. While your stakeholders likely be upset with you, in the long run it will get you more respect. You need to be clear with communication internally. If you need some of your resources to be allowed uninterrupted project time, you need to give that clear sense of urgency. Otherwise, you will not get the outcome you desire. Clear does not mean antagonising your people. You may need the same people later in the project or for a subsequent project. Do not burn bridges.

4. Undertake review

Very often when a troublesome project is completed, people are so pleased to see the back of it, no learning takes place. This is just about the worst thing you can do. You are not making sure same problems are not repeated. Wait for a reasonable period after project closure to undertake review. While things are still raw, people are more likely to be defensive and the value you get from the exercise will be limited. When you review, structure it so everyone has the ability to come forward with what they could have done better. Start yourself to show the way. If people are forthcoming, leave it at that. Your aim should be to avoid repeat, not to be punitive.

5. Follow up

Do not leave the review in a document and expect the next project to pick up on it. Use the information from your review to recommend training plans and process changes for the organisation. Present these to someone with influence within the organisation. After some time follow up on progress of the recommendations. Improvement takes hard work and tenacity.

Do you have any rules for managing troubled projects? I’d be very keen to hear.

How do I estimate based on risk?


Risk Management - Image from bigthink

Risk Management – Image from bigthink

I have previously contemplated the challenges of keeping to scope and budget and keeping customers happy. If a customer adds new requirements on to a project, it is an easy discussion to have around additional time and cost, or a reduction in scope elsewhere. Grey areas in scope aside, you can show a definite impact on the project because of an omission that needs to be rectified. Where I see challenges are in trying to prevent slow bleeds.

One approach is to state assumptions that all dependencies will be met and manage exceptions by change requests. From experience I find that is a hard way to manage. How long does it take to do a task? The answer is always depends. You may be doing a task very similar to that you have done elsewhere. However, you cannot assume it will take the same amount of effort or elapsed time. The environment where you are deploying, number of other suppliers involved and in-house expertise of your customer all play significant roles. Experience tells us that we must take into account these factors as risks when we estimate project cost and duration.

My area of expertise is in delivery of IT projects. However, I believe the principle is the same in all fields of work. In an IT context, even in simplest projects you will have a customer taking on the task of solving a business problem through a project. The supplier will be engaged to deliver the project to a scope. Usually interactions are required with subject matter experts in the business, the IT service provider for the customer (could be in-house or another supplier), possibly procurement … to note a few. There are risks that we must associate with each of the players and estimate the project accordingly. While it is difficult to create a good risk profile for a new customer, we should be able to build a reasonable picture for customers we deal with regularly.

Think of a scenario where one of the other suppliers delay delivering a component that is a pre-requisite for your delivery. It may only have been delivered a day or two late. However, you have created an optimum resourcing based on something being delivered on the agreed date. In reality, you cannot re-assign those resources unless you have significant notice of the delay. Even if you know well ahead of time, in many occasions it is impractical to re-allocate those resources to another project, due to the short available window. By the time they are up to speed with the other project, it will be time for them to start working on the original assignment. Effectively the supplier through no fault of their own ends up absorbing the cost.

Sometimes the lost time is less than days, maybe a few hours every week due to lax turnarounds to required information or pre-requisite delivery. However, at the end of a project it does end up being a significant impact. You cannot really go back with a change request every time something is delayed by an hour. This will give a new meaning to death by change request. And you can be guaranteed a breakdown in communication with your customer. How so do we then ensure projects do not suffer this fate?

PRINCE2 Risk Probability Impact Grid

PRINCE2 Risk Probability Impact Grid

The only way around this dilemma is to expect some level of these risks materialising. PRINCE2 suggests using a probability impact grid to evaluate risks. While PRINCE2 is predominantly useful for the end customer to run the project, there is no reason the suppliers cannot use similar techniques to analyse risk. It is worth analysing what your particular scale for impact or probability is to get a good feel for impact. When you are constructing your estimates and plans, have these built in.

The key message here is to initiate a change request only when the risk that you have tolerance for in your plan is exceeded. Many IT projects fail to take this into account and bleed. One can legitimately ask why doing a PERT estimate should not take these risks into account for the pessimistic scenario. The key to remember on that is when you get your technical staff to estimate the pessimistic scenario, they are taking into account pessimism from a technical point of view, whether that be an unknown pattern of software development, familiarising with new API etc. They are not taking into account human or communication risks.

In my observation, construction projects are better at taking risk budget into account than IT ones. This is possibly because a half finished construction project is an obvious reminder of a failed project. Failure of an IT project is usually a less visible eye sore. That has probably made those in IT projects lazier than we should be.

Competing with cheap opposition


Competing with cheap oppositionThe saying if you pay peanuts, you get monkeys used to be quite a true one. In traditional business models where all suppliers came from the same market that extended to projects as well. Today services are not necessarily procured from the market they are delivered. Competition is much wide ranging to different countries and even continents. Exchange rates can artificially put companies in an advantageous position. A reasonable salary in India or China will be significantly less than in the United States, Europe, Australia or New Zealand. This pits companies providing services in their own markets into a challenging situation. How can they compete?

Some companies have taken the route of your “local” as the reason to do business with them. Unfortunately, the world is a more savvy place today than some years ago … mostly. This tactic does not work as well today as once it did. The scenario is not limited to services being offered from cheap offshore companies. The response of many companies in these jurisdictions that seek to be competitive is to eliminate overheads by cutting training, limiting remuneration and benefits, removing office locations etc. to provide services on the cheap. Challenges are even higher competing against such organisations.

If you wish to maintain a semblance of quality, retain capable staff and intellectual property and seek to provide job satisfaction then there is a cost to that. The organisation cannot absorb all the cost. They are in it to make a profit at the end of the day. This cost has to be passed on to the client to make it work. Is this a futile exercise? It may seem the only way to compete is to trim expenditure at the cost of everything else.

I was having a conversation with a former colleague, who was of the opinion that he would seek quality every time. While an excellent idea in principle, it rarely works in practice when money is involved. We as human beings are programmed to look out for the best “deal” out there. You only have to look at the roaring trade retailers do around festive season. It is the appearance of value for money that attracts many. Think yourself … if you can stay at a 5 star hotel for 2 nights and for the same cost stay 7 nights at a 3 star hotel, which one would you choose? Maybe you choose a 4 star accommodation for 4 nights instead as a compromise? Companies are constantly balancing quality against cost.

A look at the car industry can help us take a guide in the IT world. Tata manufactures the cheapest car – Nano in India. It is not even marketed outside of India because cheap itself will not sell. There are quality criteria for entry into other markets. US manufacturers have for years relied on being the home brand to trade. As the petrol prices rise consumers have become more aware of better value for money with Japanese cars. At the same time many German manufacturers remain as premium brands that trade less on quantity and more on quality.

What IT companies need to do is to focus on showing value to the customer rather than trying to be cheap. There will be a set of customers that will equate cheap with value. In some cases companies will need to evaluate whether those customers are worth servicing. Some customers will go for cheaper option from an incumbent supplier, rather than an innovative and higher quality option, not because it is cheaper but because they are averse to change. These are customers that you need to keep in touch with if you believe you can offer a higher quality. They may one day develop the courage to change. Focus more on the end of the market that will recognise quality.

How do you communicate this quality? Change emphasis. You are local. What value is in it for the customer? You can respond quicker, have coverage for the full business hours, speak the same language, aware of business processes and local legislations. Trumpet your retention rates and certifications or technical skills of your staff. Build a relationship with your clients outside business – social or sport. You actually have selling points that cheaper ones do not or cannot have.

Image Credit: http://www.webdesignerdepot.com

%d bloggers like this: