Project Management in Practice

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

Facebook IPO Lessons Learned for Project Management


I was reading with some interest the various commentary about the Facebook IPO float and subsequent debacle faced by some investors. While I am not personally impacted by it, it does remind me of some common mistakes made in projects. One may call it being wise after the effect, I think of it as lessons learned.

We human beings like to think ourselves as intelligent beings. That however, does not preclude ourselves from making emotional decisions. In fact we are prone to making purchasing decisions at an emotional level. Have you ever gone to the hardware store to buy some screws, only to return home with the power tool that was on sale? Investors did get sucked in. What was desirable and cool became something that they could not live without. Facebook and its bankers took full advantage of that hype.

Lesson 1: When emotion soars, thinking suffers.

Playing ostrich never really works well . A quarter of all internet traffic today is from the mobile devices. In the next twelve to eighteen months this figure is forecast to be nearly three quarters of all traffic. Earlier this month Facebook warned they have no meaningful revenue stream from mobile. Combination of the two should have rung alarm bells on what was the largest tech public offering. It appears not many made the connection.

Lesson 2: Never assume, check your numbers.

IPO lodgment is a murky process. Everyone is looking to squeeze the maximum out of this. The aim is to raise as much capital as possible. Before you and I get a chance to get in the action, the merchant banks routinely pitch to the institutional investors to buy in. It appears Morgan Stanley not only did this, but also were more forthcoming to them regarding Facebook’s earning potential. This is now facing SEC and Senate Banking committee investigations.

Lesson 3: Making decisions with incomplete information is dangerous.

Asking price of US$38 for the Facebook IPO valued the company at US$100b. That is staggeringly four times as much as Google, which has an order of magnitude higher earnings. The ratio of price to earnings is about 200:1, many times more than both Google and Apple. Usual rate of price to earnings for listed companies is around 14 or 15:1. This information was definitely available for anyone had they wanted to analyze it.

Lesson 4: Lack of analysis compromises quality of decision making

What I wrote in this article was a quick summary of what I read. I did not necessarily know all of it, neither do I claim this to be a comprehensive analysis of what transpired. The resemblance of some of this to bad practices in project management is uncanny. Let us learn from other’s mistakes, without repeating it ourselves. It may be that people that bought into Facebook today will really make hay. If so, I will hail them as visionary :-)

Managing Projects Better


This is a presentation that I did to management a few months ago with the aim of continually improving the operations of the project office. I thought it would be a good thing to share with the community.

Managing Projects Better

View more PowerPoint from Shoaib Ahmed

Your feedback is most welcome.

Australasian trends in MSP and impact on PRINCE2


The Wellington PRINCE2 User Group met last week at the Deloitte House. The guest speaker at the event was Geoff Rankins, a programme and project management professional with over 35 years of experience across ASX50 organisations, Federal and State Governments in Australia and international not for profit organisations. He is also a contributor to PRINCE2 2009, MSP 2011, ISO 38500 and ISO 21500. Usually the user group has a format of three seven minute presentations followed by Q&A and networking on a single event. Due to the calibre of the speaker the committee adjusted the format to have only a single speaker with interactive Q&A with the speaker. Three main threads of discussion centred around trends in Australasia, MSP implementation lessons and co-existence of MSP and PRINCE2.

There were some interesting insights from Geoff regarding the pattern of adoption he has seen in Australasia. Consulting firms are using MSP to manage company mergers and state wide eHealth programmes. One of the largest construction companies is using MSP to manage building of 800 building in an 18 month period across the state of Queensland. The Australian Government Information Management Office (AGIMO) is promoting the use of MSP to the Federal Government Departments. The Capability Development Group of the Department of Defence in Australia already use both MSP and PRINCE2. There is also a trend in the various State Government Departments using MSP to deliver strategic programmes. In Australia not for profit organisations are using MSP to deliver process re-engineering and coordinating national mental health programmes. In New Zealand telecommunications and hydro-electric companies are taking up MSP as well as the national rail company and the Department of Corrections. Internationally, UNDP has adopted MSP to deliver aid programmes across 160 countries and in the UK the London Olympics is delivered through MSP. If you were ever wondering why so many examples on the MSP text appear from the London Olympics, this is the reason.

Like any other change initiatives, there is different between deciding to use MSP and adopting it. Some of the implementation challenges Geoff shared has a ring of familiarity. The biggest issue he highlighted was not treating adoption of MSP as an organisational change project on its own. Unless the organisation changes the culture of its programme delivery, success is going to be limited if at all attainable. In the same manner PRINCE2 has to be tailored to suit the organisation, so should MSP. That leads to implementations not challenging the existing environments and the necessary organisational change is not achieved. Using consultants was also identified as a limiting factor. Consultants being used must have implementation expertise, rather than simple certifications. At the same time the organisation must invest in internal capability building. In many case consultants move and and all the knowledge is lost. Consultants can help implement, but not maintain and evolve the framework as the organisation changes.

There is also a tendency to jump to a solution mode too quickly, what Geoff called inadequate “optioneering” and resulting in sub-optimal business cases. Organisations where programme management is less mature there are tendencies to treat a set of projects as a programme and not using it a vehicle for achieving organisational change. This also leads to focus to too much detail at programme level – defaulting to project management mode. The senior management in the organisation have to focus on the bigger picture of the programmes, rather than details of individual projects. Intervening too low results is focus on outputs rather than benefits and threats to them. There also needs to be a realisation that programmes are inherently more uncertain than projects and some element of learning is expected. The benefit an organisation can derive from having a well defined MSP framework are providing quick start to project business cases, oversight in project governance, escalation path to the senior management, lessons capture and dispersal across many projects. The biggest benefit of all is the focus on benefits realisation – something a PRINCE2 project is tasked with considering, but not well placed to achieve as the project is long finished before the benefits are scheduled to be achieved.

Sometimes organisations spend too much effort to identify if something they need to achieve is a project or programme. The key message from Geoff was to start with either and change the approach if necessary as the business case gets refined. Integration of PRINCE2 and MSP should happen on the basis of roles, assurance requirements and governance strategies.  The idea that resonated with me was there is nothing stopping cherry picking parts of MSP into projects if the organisation is not mature enough to handle MSP implementation. There is no reason why stakeholder engagement strategies, benefits profiles, blueprint and transition planning concepts of MSP cannot be used in a PRINCE2 project. In fact those should be transferable to any project. Right tools for the right environment.

Adoption usually comes because of governance and accountability reasons. For that reason frameworks like MSP and PRINCE2 usually are adopted by Government entities first. This then forces all service providers to comply. It appears there is substantial acceptance of MSP and PRINCE2 as Programme and Project Management frameworks in Australasia.

How do I influence to get the desired behaviour?


I attended a training by an industrial psychologist Keith McGregor covering topics on why people behave the way they do and how to use strategies to get the outcome that you desire. For the first few hours, I was thinking this is a total waste of time. By the end of the second day, I had changed my mind. While I am still not convinced about the entire content of what was presented, I did take away some strategies to help me get the outcomes I want from my project team members. Here is a quick summary of what I have taken away from the training.

Keith gave one example that stayed with me after the training. He was talking about a four year old child of his neighbour’s who constantly asked him questions about everything when he went to tend to the trees in his backyard. It got so annoying for him that he only used to go tend to the trees on Sunday mornings, when he knew the child’s parents would take him to Church. Here, a four year old child is dictating the behaviour of a trained psychologist. Now think of the opposite end of the spectrum. Many organisations have office admin workers who have to chase up after people to get the correct paperwork, so they can balance the ledger, or process the monthly payments, or reconcile the accounts. Most people have the tendency to look them as annoying. There is always someone in the organisation that is considerate to them. When the time comes for them to do something for the staff (i.e. order supplies), they will always remember those that help make their lives easier. If you paid attention, you’ll notice they always receive their supplies first, and do not have to ask for this. People consider other people that help them as their leaders at an emotional level and are usually pleased to return the favour.

A second reflection from the course was the concept of “feeding the monkeys.” The idea comes from an article published by William Oncken Jr and Donald Wass in Harvard Business Review in 1974. Here the monkey represents the next required action on a particular task. The project manager is responsible for planning, delegating, monitoring and controlling all aspects of projects, and the motivation of those involved, to achieve the project objectives within the agreed tolerances of time, cost, quality, scope and risks. Project Managers should not end up owning actions on deliverables of the specialist products produced by the projects. Project Managers must ensure that all communications end with the delivery team owning responsibility for the next action and actively remove tendencies to be told what to do. Otherwise tasks stall for the Project Manager to make a decision and project team sits waiting for it. Monkeys should be fed or shot (task cancelled), they should never be starved. Delegate tasks on projects and grow capability in the team. 

The project team members usually comprise of different personality traits. There are largely six different types of personalities and you need to temper your communication according to their dispositions. The example here was when a school child was asked what did you learn today the inevitable answer was … “nothing.” However, when the same child was asked “did you have fun today?” she could not be stopped. You can deliver the same message to different groups, with a minimal change in emphasis to get your point across. Remember, no one belongs to a single box. Observe people, find out what levers to pull.

The biggest impact a Project Manager can have is on how they respond to behaviour of the people that are working on their projects. There are only three possible responses to any behaviour. Behaviour can be rewarded, punished or ignored. When behaviour is ignored, by definition it is being extinguished. Expect the intensity of the behaviour to increase. Punishment is what will get the quickest results. However, if that is to be used to improve behaviour, it must be done where the self-esteem is not destroyed in the process. Done too often, it will cease to have any impact. Rewarding is the most sustainable response to encourage the behaviour you want. It is best to thank people, rather than praise. Praise does not allow someone to understand what is being appreciated and why. Always state the behaviour, the impact it hand and then thank. Instead of saying “you did a great job,” say “I understand you stayed back last night to help Amanda complete the release. It meant we managed to deliver the product on time. Thank you.”

As human beings our tendency is to always pay attention at the worst moments. There is maximum attention when the project is headed south. Little or no attention is paid when things are on track. We also spend most of our energy dealing with the problem children and tend to leave the well performing ones alone. This is a recipe for discontent. The biggest risk in projects is the good people will be disaffected and leave. Do not water the weeds while the plants wither away and die.

Content Acknowledgement: Keith McGregor.

Major Image Credit: http://www.duiops.net

Where is the line between agility and chaos?


We are living in an age of social media. One where opinions are best expressed in 140 characters or less, hashtags galore and needs need to be met instantly. There is a level of agility required to work well in this environment. If an organization rigidly sticks to how business used to be done, more than likely they will be left behind by others that are willing to alter course. However, can one get into the habit of altering so much that they go around in circles? There are many misconceptions about Agile. Let us explore some of those.

Aglie is NOT Agile IS
A methodology Agile is a set of principles.

  • Individuals and interactions over process and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

People have created methodologies around these principles – namely Scrum, Kanban, Extreme Programming (XP) etc.

License to dive straight into code All Agile methodologies have a significant emphasis on continually solidifying user stories. A successful delivery is judged by how closely the delivery met the user stories.
License to develop without scope User stories are the definition of scope. User stories must contain enough information for the developers to quantify a particular story “done”.
License to change your mind daily User stories are worked on continuously. More imminent a story is to be worked on; more time is spent detailing it. Adjustments to requirements are accommodated during sprint planning and treated as any other requirement, which it is being prioritised against.
License to leave half finished work floating around Most agile methodologies will restrict the number of in-flight tasks. If some of the team complete their work before others, it is their role to help others complete tasks at hand.
License to continually chop and change the team Most efficiency is gained when you arrive at a team that gels well. The sum of the capability of the team dictates the velocity at which it can operate at. Constant swapping of resources makes it near impossible to measure progress through burn-rate. One area where you expect change is in the role of the subject matter expert, based on tasks at hand.
License to pull resources mid assignment Once the sprint starts, resources are committed to getting the sprint ‘done’. It is acceptable to commit a resource to part of the sprint or a portion of the resources availability. But once committed, they see it through.
Something that only works on its own Agile is perfectly paced to be used in conjunction with other project management methodologies. For example, one can use PRINCE2 and manage by stages, where the stage boundaries represent iterations in an Agile methodology. Agile requires complete software at the end of iterations. PRINCE2 requires the ability to close a project if the business case can no longer be satisfied. Using the two together allows for tangible benefits to remain with the customer even if a project has to be cancelled.

To avoid chaos, you need a level of planning. When planning is impossible, chaos is the more likely outcome than agility.

Follow

Get every new post delivered to your Inbox.

Join 356 other followers