We all know that projects are executed with the best of intentions and with more than just the hope / want to succeed. But, what does it really take to cross the finish line and more importantly, doing so in a way that ensures that there are people (who are interested in the game and the outcome) still around to watch?

Well, here is my take on what those key hurdles (focus areas) are and why these are important factors influencing Project success (contributing to or adversely impacting) and what we can do.

1. Why are we doing this and does it still make sense? (Business Case and Benefits)

Imagine this – Someone wanted a system to register people online, and by the time the system was delivered, there was no one left to register! This is an exaggerated scenario, but still delivers a key message.

In long running projects / programs, don’t be very surprised, if by the time the project is completed, there are various issues around the fit for use and purpose / relevance aspects of the project for various reasons.

To mitigate this – ensure that all key stakeholders are aware of the Business Case and there are tangible benefits (measures) that can be realized through the proposed project. More than just awareness around this, it needs to be challenged as well. In an ideal scenario, these should then be mapped to the project and could be used to determine how successful a project was in delivering the “goods”.

The management / leadership team should not lose focus on these and should have a mechanism in place which can review the alignment of the project vis-à-vis the current-ness and relevance of the business benefits versus organizational needs (aka portfolio management). This will help avoid heartburns at a later stage, especially for long running and complex projects.

2. Who will bell the cat…Uh…Um… Er…Who is the Cat?! (Sponsorship)

I will focus on 2 key and sensitive elements – the Executive Sponsor and the Operating model for the team.

Executive Sponsor – there has to be a representative at the executive level, who wants to see this through. Who plays this role depends on the project criticality and sometimes size. In most cases, this could be a senior representative from the Business Unit (more common), or sometimes a panel comprising senior leaders from multiple units (rare), or representation from the C level (common).

Why is a Sponsor critical – well, increased visibility (for the project, within the organization), demonstrating management commitment / buy in, and ability to straighten (or fix) priorities (when needed) are some of the top reasons why a Sponsor is critical.

Now, coming to the operating model (Project Organization Structure) – in a typical scenario, if you consider the main elements of a Project team, these would usually constitute – the Business, IT and Vendor(s) teams.

More often than not, the operating model within and between these key groups is usually loosely defined, largely due to possible lack of synergies between IT and Business as well as differences in how they think and operate (at a unit level, process level and having varied priorities / interests).

While this is not a big problem in mature markets, elsewhere there is still a perceptible lack of awareness on the right level of org structure and governance that is needed, to execute projects and function cohesively, and hence this becomes an absolute focus area.

At a very high level, you should see a Project Manager / Director (representing IT) who owns the overall responsibility of delivering the Project, a Business Lead or Business Change Manager who usually owns the Requirements and signs off on the Acceptance. Priorities and commitment must have equal buy in from both sides.

This org structure should facilitate seamless communication between IT, Business and Vendors by defining ownership and inter dependencies, for deriving maximum benefits.

3. Wakey Wakey (Continuous Stakeholder Engagement)

This is another loosely defined / seldom focused area, and not much attention is paid here. This is one of the most critical aspects in any form of Project Management, as expectations across stakeholders need to be managed right.

One of the key models available to help identify the right level of attention and engagement of stakeholders is the Power/Interest Grid (Mendelow, 1991). (Refer http://businessanalystlearnings.com/ba-techniques/2013/1/23/how-to-draw-a-stakeholder-matrix)

Most projects face issues and struggle, just because of their lack of right focus in addressing this aspect. The Power/Interest Grid is a good tool to understand and define the level of attention that could be paid to stakeholders. And once you start managing stakeholders right, consistently and continuously, then every issue and challenge will garner the right support / help.

Hence the recommendation would be to create and treat the Stakeholder engagement plan as sacred as the Project Plan.

4. Tug of War (PM and PMO)

Typically, the PM and PMO functions are rolled into one, and this kind of defeats the purpose of having defined functions like PM and PMO which are very separate, especially for large and complex projects, and this causes unwarranted bottlenecks and loss of focus.

While the PM will have his/ her hands full in terms of managing the project, the PMO is usually the backbone to support in terms of ensuring resource alignment, standards adherence, uniform reporting based on metrics, project reviews and governance even.

While setting up these functions, it is obviously important to note that the PMO needs a fair bit of independent authority and operating space, and usually operates at an organization level.

5. What exactly did you mean then? (Requirements)

A perfect example to emphasize this would be – “Customer wanted a cow that produced milk, and we gave them an elephant, that still gives milk, and they are not happy!”

Now, would you want to be the one who gets to milk the Elephant? 🙂

Legacy approach usually does not dictate involvement of the Business Users beyond Requirements Analysis and up until the Acceptance Phase. This is one of the biggest factors that can determine if a project will succeed or not.

Business community must be engaged throughout the course of the project, and especially post requirements phase, when the solutioning / design is in progress, it becomes that much more important that their views are sought through interim reviews / playback sessions – where aspects like usability (look and feel) , high level design (workflow, validations) etc are walked through and early feedback is solicited.

Such early feedback usually eliminates big / worrisome issues creeping in during the acceptance phase and minimize cost of making changes identified at a later staged.

6. Beyond Docs and Decks (Status Updates and Checks)

Status Reporting and Monitoring is another key aspect of Project Management and execution.

Teams should operate in a mode where the current status of the project is not restricted to status reports alone (words and numbers – however quantitative they are). There should be a mechanism of engaging stakeholders all round, using prototype reviews, demos, design reviews etc.

More than relying only on the status report, this method will ensure that stakeholders are actively involved and there is a visible buy-in and more active engagement / participation, over and above all forms of routine status updates.

7. Did we even say this was possible? (Project Planning)

Every once in a while (I mean often), we all fall victim to (over) ambitious planning. It is entirely normal and can only be solved once we get computers to create Project Plans! J

Till such time, we need to understand that Project Planning is an art as well. While estimation is more or less a well established science / discipline, it is practically impossible to simulate all those parameters that would affect a given hypothesis around a plan, just because of the human and non-human elements involved in a project.

So what can we do here? While we leverage from best practices, lessons learnt, wisdom earned etc, from our past, we should also intentionally build a mechanism in the  plan, to test out THE  approach, understanding and limitations of all of the known and unknown assumptions, on the basis of which the planning was done.

What this means is that we execute a smaller piece of work (set of activities), findings (experience) of which can then be extrapolated / used back to optimize the overall plan, and make adjustments as necessary, before getting into a big bang mode.

This will go a long way in eliminating problems that could arise due to practical issues that hit a project like – inter and intra team “latency”,  impact of BAU on team’s availability, incorrect assumptions around lead times, overall approach etc

8. Govern the Governance

Nothing beats a project more than lack of Governance.

Typically, what passes for Governance these days is, having a governance structure in place and a plethora of governance meetings without a clear objective (going through the motions, so to say).

Governance has to be 360 degrees – in the sense, there must be an active interest and participation from both the steering and the project team level, with all key stakeholders.

People who are part of the Governance chain NEED to understand their roles and responsibilities – as important as you would explain the R&R to a Business Analyst or a Tester!

So you need to be clear, on defining this right and enforcing this right, from Day 1.

Warning signals need to be raised, discussed, understood and resolution thought through using these forums.

IF all these aspects are understood and taken care of, then, you can be rest assured that the journey will be relatively smooth for all, whatever may be the outcome.