Project Management in Practice

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

Category Archives: risk management

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

The resourcing conundrum


In almost every organisation I have worked, I have seen the dilemma of resourcing in an optimum manner. Every services organisation will try to get maximum utilisation of their staff. This is how you make good money. As Murphy would have it, there is never the perfect synergy. Either you have too much work and not enough people, or the exact opposite – too many people sitting around twiddling thumbs.

Sometimes you wish work comes in a less lumpy fashion. However, there are practicalities of procurement that get in the way. Where work is of less immediate urgency, you can try and get your clients to accept delivery at a time suitable to you. However, your clients too have certain timeline. And then there are times before the end of the financial year when people have money to spend, but your capacity take on the work may be compromised, as there is too much work.

In trying to make your pipeline less lumpy there is the chance of your customers becoming dissatisfied with you and going to the competition. So that is a delicate balance to tread. One option many organisations utilise is using contractors. My experience with contractors is mixed. I have worked with some excellent ones and some that have been on the lookout for the next contract or worse intentionally making work for themselves at the expense of the project.

Alliances and business partners could come in quite handy in these scenarios. In essence, these are the same as contractors, but an organisation rather than individuals. While you may encounter some of the same risks, you are more likely to get better quality work out of them. It is in the interest of that organisation to provide quality output. The risk comes more by introducing potential competition to your customers. What is there to stop them going to them for the next project?

If you have read this far expecting concrete suggestions, I will have to disappoint you. It will always be a judgement call based on the size of the project, the customer and their likely reaction, threat of competitors and availability of contract organisations or individual contractors. In some cases you may have to go for a combination of these or compromise an existing project to get through. I am risk averse in deliveries and prefer control of resources.

I generally prefer partnerships with organisations over individuals and mitigating risk by engaging with an organisation with different strengths to avoid future direct competition. What approaches has worked for you? Have I not considered options that you have successfully used?

Be careful not to try and squeeze every last bit of capacity out of your team. Leave some space for unstructured experimentation and self learning to ensure they keep ahead of competition. In reality you will get many fold more productivity out of them than the time they use for this.

Image Credit: LightningArt.Com

When projects go too well


As a Project Manager, I strive to ensure my projects go really well. Experience tells me that all projects will go through some difficult periods during its execution. Projects are inherently risky and not all risks, influences and impacts can be predicted in advance. That and years of experience delivering projects has made me weary about a project going too well.

Ignorance is bliss. However, when exposed the results are seldom pretty. There are many reasons why a project may appear to be going better than what is the reality. The project team may have a different world view than that of the customer. This is a very common scenario, especially in the old days of long waterfall software development projects. The advent of the Agile methodologies has come about through a desire to remove this expectation barrier through short iterations where the customer has the opportunity for feedback. That alone, however does not guarantee success.

Many times, it is much easier at the start of the project because the pressure of deadlines is not so immediate. A day’s delay here and there does not seem to pose a great danger. There seems plenty of opportunity to make up for any lost time. However, as the project progresses, this becomes less and less possible. Unless the project is planned with enormous slack, in my experience it is impossible. The student syndrome is well and truly entrenched in project teams. If someone is given more time than is needed for a particular task, they relax too much early on and only put the foot down when they think they are nearing the critical path.

In the context of a supplier delivering products of services to a customer, the early days of projects are much easier. All parties begin with the intention of getting to the end goal in a one team approach. However, the business pressures are different on the supplier and customer. Therefore, even with the best wishes, a one team approach is very difficult to sustain over a long period. Equally, when the discussion is about benefits and approaches, it is a much easier conversation to have. As soon as the conversations move towards billing for costs from the supplier side, or project assurance or performance measurement from the customer side, discussions are inevitably more difficult.

Work cultures and how individuals behave during uncertainty also play a major role in project success. Some people have the tendency to not ask for help and hope they will be able to persevere through any difficulty they are having. They consider asking for help as a sign of failure. This can lead to drastic consequences, despite well meaning people. Bringing to attention any risks or issues to late in the piece will guarantee it cannot be successfully navigated through. There is no substitute to knowing your people.

The biggest mistake I see made when projects go well early is project teams sometimes get too comfortable and stop doing the basics correctly – keeping tabs on scope, documenting decisions, communicating effectively, enforcing change control etc. People are by nature reluctant to rock a boat they consider is sailing well. If you always hear everything is going well do not be content. Do some project management by simply walking around and getting the pulse of the team. Having a good handle on whether status reports reflect reality is a must. If there are issues, it is much better to know them early.

Do not relax when projects start well. You are under less pressure and should take the opportunity to compile good project management artifacts. If things turn sour, these are what will help navigate a course.

Image Credit: The New Zealand Railways Magazine

How do I handle external pressure?


Project management principles are the same world over. However, the application of those principles vary widely depending on the type of organisation you are in and the type of external pressures you face. Here I use the word external to mean influences outside the project, rather than the organisation. PMBOK and PRINCE2 contend that the Project Manager runs the project on behalf of the governance team or the project board, so the decision on project selection and business case rests with them. Most organisations will use the experience of a Project Manager to determine the business case.

I work for a niche technology company that predominantly provides professional services and software development. Recently we have moved into the product sale market. One constant pressure we face is to limit costs of professional services in order to land a product sale. This is not unique to our company. There is always a judgement call between the appetite for cost the customer has in determining the final price. Regardless of the pressure, the effort required to deliver the outcome the customer is after does not change.

When there is internal pressure to reduce estimates, the Project Manager can negotiate with the sales staff to reduce scope as a trade off. That does not always work, as professional services companies are rarely in the position of setting the agenda. More often than not, they are responding to a demand based on gaps in the customers core staff. Usually everything is a must have. The question at this point becomes not a project management one, but a strategic one for the company. The project may be desirable despite possible overruns in the current project. There may be future projects, or may provide foot in the door to a particular segment of the market or may be a key reference customer. It is the Project Manager’s responsibility to quantify the cost appropriately, so the management can make an informed choice about how much risk they wish to carry. Simply adhering to the wishes of the sales staff is a dangerous game to play.

A second external pressure that constantly challenges project estimates is the pricing of competitors. This is a more difficult proposition to deal with, as the parties are outside the organisation and you will never have the full facts to compare your estimates. The opposition may be desperate and willing to undercut any estimate you provide. Equally, they could be significantly underestimating the risks and deliverables. The key here is to not look at your competitors on a project basis. Look at the pattern over a period of time and see if they are making a success of those projects where you are being undercut. If they are, then challenge your teams to sharpen their estimates. Be mindful though, there will always be cowboys in the market and clients willing to make to do on shoe strings. If that is the case, move on. Choosing to compete at that end of the market will be at the cost of reputation and professional satisfaction.

A third challenge a project manager faces is trying to recommend when a project should be terminated. Usually business cases are made to start a project. It is less common to continually validate the benefits sought in the business case as the project is in flight. Things can get complicated if it is a pet project of someone higher up in the organisation. It is imperative that a Project Manager is aware of what benefits are expected out of the project. That will allow for quantifying accurately if the benefits sought can be achieved based on realities of the project. Nothing is black and white in projects. That is why they are temporary and higher risk than Business As Usual activities. In some cases the organisation may decide risk to reputation is worse than loss in a project.

Projects are inherently risky and pressures are a fact of life. How we deal with the risk and how we quantify it to management is where a good Project Manager stands out. It is the organisation that makes the decision, but it is the Project Manager that provides the analysis to facilitate that decision.

Under promise over deliver?


Under promise

I was part of an interview panel recently to employ a new Project Manager. Interview was iterating towards a good outcome and we started discussing the philosophy of project delivery. The specific phrase that came up was the often used under promise, over deliver and it’s appropriateness. It was a very interesting discussion, one that I thought I’d share.

The classic reason Project Managers try to under promise and over deliver is to mitigate risk. Once bitten, twice shy. This approach has come from project managers who have been burned by failing to control expectations with their stakeholders. The reason for this failure may have been varied – from unrealistic targets or unreasonable stakeholders. Whatever the case, minimizing impact on the project is the prime concern for them and has led to this approach finding a strong foothold. Perception is reality in IT service delivery. If the stakeholder’s expectations are being met, usually they’ll consider the project value for money.

While this provides for a level of Cover from risk, it goes against open and transparent communication. All the interaction is between competent professionals. This level of communication gap should not be desirable. In saying that the Project Managers currently intentionally setting lower expectations have at one point tried that. Is that an indication that open communication is an aspiration that can never be reached?

I find this all depends on the maturity of all the stakeholders. How you communicate to them usually mirrors how you communicate with your family. There are those family members who are mature enough and you can call a spade a spade. With them, you can aspire to have a transparent communication channel. Set the expectations and if something is to go south, explain the reasons and how the course will be altered to meet the best outcome. There are always some in the family who really care, but don’t get it. In stakeholder terms it is really important to keep on-side, but you probably want to ensure a need to know information flow only. Then there are the in-laws, who you never seem to be able to win over come what may. This is the audience where under promise and over deliver is an entirely valid strategy.

Aspire to openness as the first choice. But be prepared to alter strategy depending on the interest, influence and nature of the stakeholder.

%d bloggers like this: