Project Management in Practice

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

Category Archives: Stakeholder management

5 Questions every Project Manager must ask


5 Questions Project Manager must askProjects are inherently risky endeavours and require plenty of shepherding to ensure successful completion and the desired results. Key to successful project management is clarity of understanding on what you are trying to deliver. It is easier said than done. Different people can read the same requirements and have different impressions of deliverables. I’ve been thinking about some of the strategies I have used and seen successfully applied. Following is a set that I have found very useful. I find asking some, if not all of these questions consistently gives me best chance of success.

Q1: Can I focus on outcomes rather than outputs?

Most projects in my experience are too preoccupied with delivering the outputs. Predominant procurement methods are partly to blame for the culture of judging project success by its outputs. For example, an output may be a new software but the desired outcome is faster processing of orders. No one has monopoly on good ideas. In many instances requirements are gathered prior to projects starting, where assumptions fail on first inspection. Ask yourself if you have the ability to go back to the stakeholders if you were faced with such a scenario. If it is output that you must produce regardless of outcome, then your chances of success are low. On the other hand, if you know what the desired outcome is, you can articulate why a particular option may have more merit than another.

Q2: Do I have enough sponsor involvement?

I see plenty of projects languishing with project managers struggling to get buy in from various stakeholders. Any organisation is a political one by nature. There are stakeholders with various views. Some may have been keen to undertake the project; others may not have been so enthusiastic. Organisations have to prioritise their portfolio and you may require contribution from those that had their projects or ideas passed over. If you try to manage your way out of that, there is little hope of success. This is where involvement of your sponsor is key. They are usually in a position of authority to ensure cooperation, provide you with strategies to work within the organisation and remove obstacles before they become showstoppers.

Q3: Am I working to artificial deadlines?

I see many instances where projects are running to particular deadlines not because of level of effort required, but because someone in management has undertaken to have the outputs delivered at a certain date. Fred Brooks Jr, father of IBM/360 is one of my favourite authors. In his book “The Mythical Man Month” he gives a great example – It takes nine months childbirth. You can put nine women, you’ll get nine children, but it’ll take you nine months (paraphrasing). The effort is what it is. If artificial deadlines are to be met, it must come by trading off scope in the project. Simply throwing more staff at it does not solve the problem. In some cases you may be able to reduce elapsed time by throwing more resources. But beware, what takes one person 100 hours, will not be delivered by 100 people in one hour. There is a cost of communication and coordination.

Q4: How am I going to transition the outputs to the business?

So you have a set of outputs from the project … process, software, document, building … whatever these may be. Now what? The only way the customer can achieve any benefit out of these is once you have transitioned these into the business. I see many projects leaving transition planning to the end. That is always too late. The end of the project is usually a swarm of activity, many planned, many unplanned but necessary. You need to have planned your transition up front. Organisations have various levels of change appetite. You need to consider if you can take a big bang approach or need gradual transition into service.

Q5: What does my gut say?

If you are an experienced project manager, then trust your instincts. Our brains are programmed to catch patterns. You may get a feeling that something isn’t quite right. I have seen project managers ignore that if they have not been able to verify if there is indeed a need for concern. By the time they have realised what it is it is too late. If your gut tells you something is wrong, stay at it. Until you find out what it is. Have a method that you apply to it. Go through your risk register, deliverables, product descriptions, milestones. At first if you don’t see it, stay vigilant. Ignoring it is just about the worst thing you can do.

There are bound to be plenty of other questions that you should ask yourself. What is your list?

Image Credit: All-Free-Download.Com

Light at the end of the tunnel


Ever feel like there is too much to do and not enough hours in the day? I have just had a couple of weeks like that. Each day I worried how I’m going to get through the tasks at hand without dropping the ball on something else. It is not uncommon in professional services. Work is lumpy in nature and you have to ride the rough with the smooth.

Light at the end of the tunnel - Project Resource Management

I have made the statement of the lumpy nature of professional services work several times, but seldom put any thought to why that is the case. The most obvious reason I have seen is the fiscal year and budget allocations. In many organisations, unused budget is lost from future budgets and there is incentive for customers to hold on to budget until the last possible moment and only commit to projects once all their other costs have been accounted for. That leads to a stream of projects at the end of the fiscal year, as organisations are more confident that they do not need this budget to cover for risks in other areas.

There are holiday seasons which traditionally see a lot of staff leave. From an IT perspective this includes a lot of change freezes at various organisations both suppliers and customers. That automatically means less activities, because of system constraints. I find this is not a bad constraint, as inevitably our capacity to provide services is also low because of high leave demands.

The risk element is during school vacations, where a lot of staff want to take leave but is harder to adjust customer expectations around delivery timeframes. It is a good practice to ask for early visibility of leave requests during these times and to have a record of previous leave taken. This would allow a services company to be fair in allowing leave to staff over the course of the year. A bit of flexibility is required from everyone here. The services company itself is also obliged to set the expectation with the customer about delivery based on staff availability. It is a hard discussion to have with key customers, who have a lot of influence.

A lot of the challenges identified are quite common to most organisations and not necessarily specific to services companies. The challenge comes in the sales cycle and the desire to maximise the utilisation of resources. Higher utilisation, more profitable the company. By definition, there is less slack and less agility. A particularly efficient few months sets management expectation that high utilisation is manageable for the duration of the year, when it is not necessarily the case. Revenue expectations therefore needs to be balanced with reality of resource management.

From my point of view, It appears that the particular wave of new work may be getting to a manageable point now. However, there is a conference that is nearly here. I am presenting a day long workshop on project management in our particular industry sector, which takes a lot of effort to prepare for. In today’s environment no one has the luxury of complain about being busy. That is a sign that the company is doing better than most. We are also hiring, so my challenges on agility may be relieved somewhat.

It now looks like there is light at the end of the tunnel. Hopefully it is not a freight train heading my way.

Image Credit: lindsredding.com

Building capability in organisations


My personal reflection time during the week is on Saturday mornings, when I take my children to the local swimming pool for lessons. I was looking at the pool this week, with children of various abilities learning to swim – all in separate lanes. I recalled how my children had gone through the grades. It occured to me that building capability in organisations is an identical process. If you try to go to the quick lane before existing skills are bedded in, you will sink.

Business Change

I have been in the process of delivering a geospatial capability improvement plan for a company in the energy sector. This organisation had expressed a view that it wanted to get the process under way immediately. However, our assessment based on stakeholder feedback and existing capability, indicated the organisation had a low change appetite. This conclusion was accepted by the stakeholders.

As a result, we recommended a multi-phase approach with the first phase centralising disparate systems and processes, a following phase increasing awareness by integration with other business systems and a mature phase looking at bespoke capability for high return on investment analyses. It is however the final phase capabilities that the management is most keen on. In this instance we have been very fortunate to have successfully achieved by in from the stakeholders on the phased approach.

Getting to mature capability from little or no capability is not something that can be achieved successfully. The first two phases and the time it takes to bed those capabilities in are like teaching the children to breath under water and float, before they can be taught the various strokes. Before getting to lane 8, you need to have mastered lanes 1 through 7. Without this you will be swimming upstream – forgive the pun.

Beware trying to deliver the desired future state in one go. Be prepared to go through intermediate states if necessary. Success is not what cool applications the project delivers, it is what business advantages the organisation can achieve through those.

Image Credit: ChinoHills.Com

Expectation is reality


We hear about perception being reality in service management space. When you are dealing with projects, expectation become the be all and and end all. How your project is perceived is proportional to the level of expectation about the outcomes that you have built.

Expectation Management

In the project paradigm, cost is the easiest attribute to communicate. If the expectation in the business is that a particular deliverable will cost 100 hours and your team delivers it in 105, it will receive somewhat begrudging acceptance. 110 will get people thinking whether it was worth the effort. Conversely, if you had built the expectation that the cost would be 120 hours, then even if you spen 115, the business will consider it a great delivery.

This may sound non-sensical, but it is the truth. How does one go about building this expectation? Do you just inflate estimates to achieve this? You cannot necessarily do that. If you are a monopoly supplier like inhouse team, then you may be able to get away with consistently over estimating the effort. In a services business, there is competition for this work and you do not want to turn away business by being too conservative.

At the same time, you do not want to be forever undercutting your competition to get work. In that scenario, you are always left with the scraps to fight over. You are in it to make a profit. If my cost is going to be more than my fees, then it makes no sense to take the work on. This can be a difficult juggling act unless your sales and services teams work closely.

Expectation is not only some thing that you as a Project Manager end up managing from the customer side. What is a good project from a deliverables point of view, may not be a great financial success. If you are running a project on a time and materials basis and are accomplishing things much quicker than anticipated, you are in fact depriving yourself of income. How do you avoid that? I recommend undertaking additional testing and documentation to ensure higher quality.

If the same project is being delivered on a fixed fee basis then the drivers are different. Your motivation now is to ensure the minimum effort you can spend to have the outputs delivered. You can make good profit by being efficient. Yet, some customers will begrudge that. Your work may have saved the client 100 hours of pain and priced accordingly. But if you achieve that in 80, the client is upset with you being accused of taking them for a ride. Yet, the same customer conveniently forgets that you carried the risk on this and had the project taken 120 hours, you would have been forking out services for no fee. We want to have our cake, and eat it too.

Then here are always those projects, where the customers have a want that is far out of proportion of their cost appetite. Be wary of this. It is a very common occurrence. It may sound like a good idea at the inception of the project to sharpen your estimates to land the work. This can only lead to bad work. You are setting the project team up to having to cut corners. If you really have to discount, do so on the basis of rates. The work is what it is. There is no up-side to compromise on quality.

What makes things difficult is that there is no right or wrong answer. It totally depends on the environment.

Image Credit: pretensesoup.wordpress.com

Managing Projects Better

%d bloggers like this: