In previous episodes of this blog I have focused upon some of the answers provided to the proposition in a quasi chronological fashion - at least from a Project Management perspective. We have our hypothetical elephant in a state were it is ready for consumption plus of course we have had the cliched management answer of "one bite at a time".

With our elephant stored the next step in the process would be to cook and prepare it for consumption. My students in the past have come up with a variety of recipes and ways of cooking the elephant as raw elephant is probably only for the predators out there. Recipes have included Jumbo Jambalaya, Barbar Burgers and for the carnivores BBQ and slow roasted versions.

Consuming the elephant comes next and I have had a few students suggest "with a knife and fork" - how very civilised. Others have suggested inviting a large number of friends to participate in the process, many hands make light work after all.

In addition to the chronological and completer finisher responses offered I have had other suggestions to the proposition that have all sought to evade the challenge altogether. Paying someone else to consume the elephant is a popular call along with simply refusing to tackle the challenge.

Among the more interesting responses have been the following.

Ask others how they did it?Make an elephant out of something more appealing and eat that.

Intriguingly over all the years that I have been asking this question of my students only three people have ever some up with the following suggestion which is an interesting reflection on human nature and to an extent the antithesis of good project management.

"I'll eat the tasty bits first!"

Apart from knowing what is and is not tasty this answer provides an interesting insight into human nature and a classic problem addressed by effective project management. We tend to do the things that we like doing and postpone or avoid those things that we dislike, the result being that the longer we leave it the worse it gets - the classic self fulfiling prophecy.

In project management the focus is upon doing what needs to be done when it needs to be done. This can mean having to tackle some less than tasty activities early on but the benefit is that there can also sometimes be something to look forward to apart obviously from the end of the project itself.

So we have agreement on what an elephant is courtesy of answering the question "what do you mean by an elephant?" so what next?

A classic response now that we know what we are dealing with is to go find an elephant. As they are not native to the UK that presents a bit of a problem. Did anyone mention a travel budget?, perhaps not. For the sake of expediency we typically skip discussing all the things that might be involved in getting to where we might possibly find an elephant and move on to the how would you eat an elephant question, my groups tend to be focused on the proposition rather than the peripherals.

The next step identified by most groups is the grizzly prospect of having to despatch the poor elephant, again my groups tend to exhibit a common theme, namely that killing elephants is not a nice thing to do. However we are on a mission so what needs must!

As an aside and returning to the "what do you mean by an elephant?" you may recall that in part 1 I hinted that perhaps there was something missing from my definition of what an elephant is, to recap.

"an elephant is a four legged animal, grey in colour, native to either Africa or India, a herbivore, notable for having tusks and a trunk, supposedly possessed of a prodigious memory".

The word missing from this definition is large, most people when asked to describe an elephant will mention its size, it is after all the largest living land mammal - the largest ever found weighed 11,000 Kg.

Some people latch on to this omission - lets eat a baby elephant! Its small so there is less to consume and it will be more tender than a mature elephant. As you can imagine this proposition is greeted with dismay and horror by some people in the classroom. Thankfully we are engaging in a hypothetical situation and hopefully none of the people attending my courses are so ruthless as to descend to the point where killing a baby elephant is a deemed a good idea.

Having selected and despatched our elephant my groups identify various options, the most practical being that we need somewhere to store our deceased elephant as the prospect of rancid elephant meat for dinner does not appeal. So a big chiller is required and of course the means to transport and deposit our deceased elephant in said chiller.

It is worth pointing out that whilst I am describing events in a quasi chronological fashion my groups have tended to offer up suggestions in a random fashion as the exercise requires them to provide a different answer to any that have been provided before.

One last thing for this part of the blog - there will by now be some of you screaming out the cliched management answer "cut it in to small pieces and eat is a piece at a time" invariably in my groups there is someone who knows this answer and who is holding back. Frustratingly for them someone who didn't know the answer to begin with will have worked it out by the time that it comes around to their turn to provide a suggestion, the pressure of having to come up with something and seeing other people suggest what they were going to suggest does tend to concentrate the mind and force people into creative thinking.

As part of my Project Management theory training I have sometimes confronted my classroom with this problem "how would you eat an elephant?" There are invariably some who have heard this question before, I ask them to keep the answer to themselves and then press other students for a suggestion, going round the classroom asking each person in turn for an answer. I explain that the question is not intended to offend animal lovers or vegetarians and that the question has to be answered.

Over the years I have had some very interesting answers to this question and I thought I would share some of them with you just to indicate the many answers there can be to this proposition.

First of all I have had some students ask "what do you mean by an elephant?" - now that, despite the snorts of derision from fellow students, is a pretty intelligent question and illustrates an important point when it comes to projects. Typically it is a question that is posed by those with some form of requirements analysis background. What do I understand from what you have said?

​Having a clear and unambiguous understanding of the problem you can begin to devise a solution. If you think you know what the problem is and don't validate this with the customer you can very quickly charge off in the wrong direction. Avoid making assumptions, ensure clarity wherever possible.

My answer to this question has tended to be along the lines of "an elephant is a four legged animal, grey in colour, native to either Africa or India, a herbivore, notable for having tusks and a trunk, supposedly possessed of a prodigious memory".

That tends to satisfy the questioners - you may note that I have been careful in the definition provided and you may feel that something has been omitted, all will become clear in subsequent parts of this Blog.

​I was once asked by one of my students to provide a comparative example of a good project and a bad project. Whilst no two projects are ever exactly the same after a bit of thought I chose to provide an example comparing the Wembley Stadium project with the Arsenal Emirates stadium project. My support of Arsenal of course had nothing to do with that choice!

​Both stadiums were built within the first decade of this century and both are in North London so they provide suitable examples for a comparison. Wembley has a capacity of 90,000 whereas The Emirates is limited to just 60,432. Wembley Stadium was built between 2002 and 2007 whereas The Emirates was built between 2004 and 2006, so straightaway there is a difference in the two projects, 5 years versus 2 - one nil to the Arsenal!

Whilst Wembley has a capacity 50% greater than that of the Emirates it cost £757 Million to build compared to £390 Million for The Emirates. So a price tag of nearly double for a capacity only 50% greater - two nil to the Arsenal!

Both projects faced challenges in terms of accessibility for construction and working around the existing built environment, if anything Wembley had it easier on this score as the site already existed and merely required demolition of the old, iconic, but sadly no longer suitable stadium.

So why the huge difference between the two projects in terms of time and budget?The Wembley Stadium project was handicapped by politics and numerous stakeholders all with an opinion and quite a few with the opportunity to exert influence whereas The Emirates stadium had a limited number of stakeholders and the benefit of a clear vision from the outset.

The Wembley Stadium project had plenty of chiefs, drawn from the ranks of the great and the good, in part because a new national stadium was supposedly deserving of such an illustrious leadership team. Arsenal on the other hand had a lean and mean team dedicated to the project. As any PRINCE2 advocate will tell you having a large number of people on a project board is a recipe for problems as achieving consensus can be nigh on impossible. Whilst I am not advocating the approach of Gianni Agnelli I would suggest that big is not always better.

The leadership team for The Emirates were primarily drawn from within the club so there was both a common aim and perhaps more importantly common commercial acumen.

​Both projects took a long time to get from the drawing board to breaking ground. In the case of the The Emirates this involved delicate negotiations with numerous occupants of premises occupying the proposed site, overcoming objections from the local community and some compulsory purchase orders. Wembley on the other hand had the backing of the local community and the benefit of being a replacement for what had been there before.

Wembley Stadium was also best by changing requirements, initially it was intended to be a venue for football and athletics - much as a camel can be regarded as a horse designed by committee, mixing football and athletics in the one venue is never going to result in a satisfactory outcome. Just witness complaints from fans of West Ham now that they have moved to what was the Olympic Stadium in Stratford.

The Emirates stadium on the other hand was clearly defined from the outset and once a design and plan had been agreed there were few if any changes made, certainly none that would impact significantly on time, budget or quality.The grand arch that signifies Wembley Stadium was a "design statement" - not only did it add disproportionate cost to the project but a dispute between the main contractors on the project and the specialist contractors for the arch added a year to the project due to changes made by the main contractor design team and ultimately led to the specialist contractors quitting the project.

One more factor of influence was that The Emirates Stadium project was paid for by Arsenal football club whereas Wembley Stadium was financed by public funds of one sort or another so the people making decisions that impacted on costs were not the ones bearing the cost itself.

Once both projects were up and operational a further difference manifested itself. The quality of the playing surface.The pitch at Wembley has been relaid 10 times between 2007 and 2010 when it was finally replaced with a semi-artificial pitch. When designing The Emirates stadium the ground staff were consulted on what is needed to help grass grow. As a result the undulating roof of The Emirates and the open "curtain" between the facade and the roof allow for ventilation and natural light and an excellent playing surface as a result. Not exactly a small detail but perhaps the best signifier of the difference between the two projects - get the input of the right people when required.

So there you have it, a slightly biased but reasonably honest comparison of two projects with very similar objectives but significantly different outcomes. The final score is not in doubt - a resounding win for The Arsenal!

When Microsoft released Project 2010 one of the new features of the scheduling tool was the ability to include Inactive Tasks.

You may well be underwhelmed or even unaware of the possibilities of Inactive tasks. In this article I explore some of the ways this feature has been used by the people I have worked with when deploying Project Server or running training sessions on Microsoft Project. The examples I provide here are by no means the definitive guide, there are likely to be many ingenious uses for them devised by users as they become more familiar with this feature in Microsoft Project. The official line from Microsoft when announcing this feature was that it allows for simplified planning and what-if analysis, suitably vague there from Microsoft.

Here are several scenarios where Inactive tasks could be of significant benefit when crafting a project schedule.Scope Change:

The one thing you can be assured of in a project is that things will change and that then things will change again. How many times have you had to remove and then reinstate tasks due to changes being made and then unmade? With inactive tasks you can simply mark a task as being inactive should it be removed from the scope of your project. A record of it is retained in the schedule but it has no bearing on time, work or cost in the project plan. If the task is reinstated it is simply marked as being active once more.

This approach avoids the need for differing versions of the same project plan having to be maintained by the Project Manager. Another useful aspect of this feature is that you can record just how many tasks are recorded as being inactive over the lifecycle of a project which can be a powerful illustration of the disruptive effects of incessant change and also the sources of such change!Risk Management:

Projects and Risks go hand in hand, invariably a Project is initiated to pursue an opportunity - where there are opportunities there are bound to be risks.

Project Server provides a useful mechanism for tracking risks in the Project Site, an associated SharePoint workspace that is provisioned when a project is first published. Project Sites incorporate a reasonably robust approach to risk tracking. In Risk Analysis we identify potential risks and plan for them accordingly. Our risk list in SharePoint can identify the impact of risk, our mitigation strategy and our contingency plans.

Inactive tasks can be built into a project plan to model mitigation actions that may be required should a risk manifest itself. In risk management the watch words are “this shouldn’t happen, but it if does...” thus inactive tasks can be employed to both allow for mitigation and perhaps more importantly remind people of the potential for risk and the proposed actions that have been agreed to mitigate the risk. Should a risk occur allowing for it in the plan is as simple as activating the relevant inactive task.Branching Logic:

Have you ever been asked to model different scenarios for the same problem? With inactive tasks you can illustrate the impact of different scenarios in a single project plan.

You might have a phase or stage of a project that could be run in-house or outsourced. In-house will likely take longer due to resource availability whereas outsourcing whilst quicker comes at a price. You can create a plan where two activities have the same predecessor and same successor, this could include an entire section of the plan represented by Summary Tasks (making a Summary Task inactive makes all its subtasks inactive simultaneously). Taking the in-house route the impact on the projects overall time and budget would be different to taking the outsourced option. This gives you the opportunity to consider your options in a reasonably informed fashion.Change Management:

Working in a robustly governed environment you may well employ rigorous change management processes. I recently worked on a program where key Milestones were subject to Change Control. The Change Control process allowed for changes to key Milestones, the addition and removal of key Milestones from projects in the program. Whilst our change log contained a record of Milestones that had been approved for removal it was agreed that deleting such Milestones from the project plans was an unsatisfactory way of managing this change. By marking such removed Milestones as inactive we retained them in the plans as a matter of record and were able to provide some powerful reporting on these changes direct from the data contained in Project Server rather than having to reference the Change Log itself.

​No doubt seasoned users of Microsoft Project will come up with even more imaginative uses of this new feature of Microsoft Project, if you can think of any be sure to let me know. I will of course let you know should I come up with any more ideas myself.

Dominic Moss trades as Projectability"helping your people achieve more"- providing customers with expert guidance and training on the use of Microsoft Project, Project Server and the principles of effective Project Management.

​The operation was a success but the patient died – not exactly the news any of us would want to hear if it was our loved one who was the patient. So how does such a statement relate to Portfolio Management?​Quite simple really, if you are doing the wrong projects right then your efforts are being seriously misdirected and your organisation is not achieving optimum business value.

Project Portfolio Management (PPM) can be defined as:

“The continuous process of identifying, selecting and managing a portfolio of projects in alignment with key performance metrics and strategic business objectives”

In essence PPM is doing the right projects right.

On the road to project maturity organisations will frequently improve processes first as it is a relatively easy win. They can typically engage those affected by the change in developing the processes. Achieving a fully optimised Project Management culture, the highest level of Project Management maturity as identified by the SEI and other bodies, is an aspiration that is very rarely realised.

Most organisations seeking to improve their Project Management maturity are lucky to achieve level 3 out of 5. Achieving levels 1 & 2 typically deliver gains that are out of proportion to the gains to be derived from persisting and aiming for level 5, the optimised organisation. Like any discipline the transition from novice to competent is fairly swift and satisfying, making the transition from player to elite competitor is much more of a challenge.

A big danger of being focused purely on the attainment of Project Management Maturity is that it can become self-serving or self-referential as it is exclusively focused on delivering projects on time, within budget and to the agreed standard (Scope/Quality) – nowhere in this lexicon is there any focus on business value or notions of success as far as the sponsor or customer are concerned.

Doing projects right is of little merit if the projects are wrongly aligned as far as corporate strategy is concerned. When Microsoft launched Project Server 2007 one of their stated aims was to raise the profile of projects undertaken by organisations and to more closely align projects to organisational strategy and objectives. The Portfolio Analysis companion product to Microsoft Project Server 2007 sought to address the growing demand for more rigorous, accountable and transparent project and portfolio selections.

With subsequent releases of the Project Server product Portfolio Analysis is a standard element of the product and as such offers many more organisations the opportunity to focus upon doing the right projects. The interface has also been improved with each iteration making the adoption of Portfolio Analysis a less overwhelming proposition.

For a lot of users however Portfolio Analysis is not an immediate requirement and in a lot of cases it tends to be regarded with a degree of suspicion, primarily due to a lack of awareness as to its capabilities and potential.

Whilst the configuration and creation of Portfolio Analysis is an involved and complex process it is well worth persisting with as the results it can generate are invariably illuminating and sometimes surprising.

Portfolio Analysis is primarily focused upon achieving strategic value and the effective deployment of valuable resource or identifying shortfalls in available resource and identifying skills deficits and when they need to be resolved in order to support the portfolio.

As part of the Portfolio Analysis projects are ranked by priority as a result of Strategic Value Scoring, Project Impact Assessments, Pairwise Analysis and Strategic Driver Prioritisation – as I mentioned earlier the process is complex, however the interface for Portfolio Analysis in Project Server is logical and intuitive to follow in a step by step process. The results of this scoring approach deliver a list of proposed projects ranked by priority from highest to lowest priority with the sum of their priorities being 100% - do all the projects and you achieve 100% strategic value, simple!

For the more sophisticated amongst you it is possible to augment the Analysis with additional metrics such as Return on Investment – the only problem with these optional additions to the analysis is that they could provide some people with the opportunity to “game” the process by offering up values that distort and favourably misrepresent the value of their projects.

So far so what? Where Portfolio Analysis becomes intriguing is when we introduce limitations on both budget and resource. The Resource element is intriguing but for the remainder of this article I am going to focus upon the budget constraint.

With an unlimited budget we could undertake all proposed projects and supposedly achieve 100% business value, fantastic! Sadly it is highly unlikely that all the funding required to undertake all of the proposed projects will always be available.

Faced with such a situation the normal uninformed response would be simply to allocate the budget starting with the highest priority project and selecting further projects until all the funding available has been allocated, this would appear to be a reasonable and responsible approach.

Intriguingly Portfolio Analysis would deliver a subtly different selection of projects and in all probability deliver greater strategic value than the uninformed approach would achieve. A reduction in allocated budget is not reflected by a pro-rata reduction in strategic value, for example a reduction of the budget for a portfolio to 75% may typically see a Portfolio Analysis selection of projects that deliver 84% strategic value. This phenomenon has been christened the “efficient frontier” in Portfolio Analysis and can result in an unexpected selection of projects being proposed for a portfolio. The intent is focused upon ensuring that all strategic objectives are addressed and a balanced portfolio of projects identified.Further nuancing can be achieved by including dependencies and mutual inclusion or exclusion. In essence we must do Project N if Project F is selected or alternatively there is no point in doing Project T if Project L is excluded.

A key benefit of the Portfolio Analysis process is that it eliminates politics and ego and reduces the Portfolio selection down to a population of Projects identified by agreed objective criteria.

I worked with an organisation that had an annual budget that could be allocated to research projects. Historically achieving consensus as to which projects should be undertaken was a time consuming and frustrating process – achieving common agreement was nigh on impossible as there was always someone adding one more consideration to the discussion thereby prompting yet another round of argument and counter argument. By adopting Portfolio Analysis there were clear “rules of engagement” and the selection process took a fraction of the time it used to take.

Whilst Portfolio Analysis provides a selected population of projects based upon agreed criteria it is possible to “force-in” or “force-out” selected projects. This introduces a human element to the selection process but can have a detrimental impact on strategic value. A Project Sponsor might demand that their pet project be included when the objective analysis has excluded it, however this will likely come at a price in terms of reduced strategic value – in such situations the ego may have to give way to pragmatism. Would you really be prepared to sacrifice 4% strategic value just so that your pet project is done?

With senior decision makers being faced with greater and greater accountability the Portfolio Analysis approach can provide demonstrable evidence that decisions on Portfolio Selection were taken on rational and objective criteria with the aim of maximising business benefit.

So how does this approach compare to techniques you currently employ when it comes to Project Selection? If you haven’t done so yet it might well be worth exploring the capabilities of this element of the Project Server offering.

Apologies for the title, it was the closest I could get to Rubik – anyhow a quick History lesson for those of you who may have heard the term but not know its provenance.The Rubicon is a river near Rome and the convention was that a victorious Roman General returning from a successful campaign to the centre of the Roman Empire would stop at the river bank with his army and go no further. Crossing the Rubicon was tantamount to a declaration of war on the democratic government of the city of Rome and the Roman Empire itself.My reason for referring to Rubik is the eponymous Cube. If you are familiar with this puzzle you will know how the changes that you make can have impacts that only serve to complicate things even more just when you thought you were on the cusp of achieving resolution. You will also no doubt appreciate the pretty patterns that can emerge from the mix of colours employed on the 6 faces of the cube. Whilst they may be appealing and attractive they are invariably not what you want to see.From my experience in promoting Project Server related services a common phenomenon is the proud unveiling of the clients sophisticated Excel Spreadsheet solution for managing the workload of their people. Some of the examples are a riot of coloured cells, not dissimilar to a Rubik’s Cube – hence the reference.I have seen some seriously impressive examples in my time but without exception the problem that these in-house solutions struggle with is the inevitable change that can occur in projects and the fact that they can only be updated by one person at a time.Whilst the Spreadsheets I have seen are without doubt very sophisticated they struggle with change, do not always include all the projects being undertaken by the company and need constant updating to keep on top of changeable circumstances. These solutions can also struggle in identifying suitable candidates for work that is immediate and reactive rather than planned. Factor in the reality that people take time off work for personal reasons and things can quickly go awry.When the capabilities of Project Server are demonstrated along with the ability to analyse information in real time and make informed decisions confident in the knowledge that those decisions are based upon fully up to date information there is invariably a resigned sigh – it is just so much easier with the Project Server solution. This ease of use and immediacy of data can in themselves represent a significant cost saving for most organisations, consider the fact that the data is generated and updated as a matter of course, that it can be used to report by an almost limitless number of criteria and that the information can be made immediately available to a wide audience of recipientsI worked with a client where it was acknowledged that each and every one of their Project Managers spend the best part of 2 days per month compiling reports for senior management. A simple calculation would suggest that in their case the time saving on this activity alone would cover the cost of adopting and implementing Project Server in just 2 months. It might be worth you asking just how much time your managers currently spend putting together monthly reports.These cost savings though can be just the beginning of the value that a successful deployment of Project Server can deliver.Being provided with accurate and up to date information in a timely fashion can allow senior management to make informed decisions with greater confidence and to make these decisions in a more timely fashion than might previously have been the case.Having the confidence in the integrity of the information being provided is again a great benefit of the Project Server solution. In my next article I intend to focus upon understanding your schedule and why it is the way that it is.Perhaps you should consider crossing the Rubicon and declaring war on time consuming manual processes considering the options that are available to you.

Author

Dominic Moss is a respected authority on Microsoft Project Server and Microsoft Project - he has 20 years experience in helping people get maximum benefit from their use of these tools. His value to customers is his extensive product knowledge allied to real life project management experience, meaning he can not only demonstrate principles but provide context too.