Areas I focus on to deliver Project Success

Wow, it's been around 18 years since I joined the Project Management arena, I still remember it like yesterday. Wet behind the ears but an eagerness and hunger to learn that has still not gone away. I thought it might help any newbies into the Project Management line some lessons that I have learnt over the years. I am not saying this is the only way but there maybe elements you might want to take. There have been some areas that I have learnt that have helped me deliver many of my projects and even programmes successfully. I thought I would share my thoughts:

Plan, plan plan

Planning is the ability to define the fundamental components of a project in terms of its scope, deliverables, time scales, resource requirements and budget. It also includes the production of broader plans incorporating risk and quality to provide a consolidated overview of a project.

The key to a successful project is in the planning. Having a project plan is the first thing I do when undertaking any project. I have noticed in some organisations that project planning is ignored in favour of getting on with the work. I tend to follow a four step approach to my planning in any project or programme that I undertake. These are as follows;

Step 1 Understand the project goals,

Step 2 What are the deliverables?

Step 3 Create the schedule

Step 4 Don't forget the plans (resource, risk management and communications).

The goals are met when they have met the needs off the stakeholders. In the planning stage I identify the stakeholders and ensuring what their goals are and recorded in the plan. I create a list with priorities in agreement with the stakeholders. 

Using the goals that I have defined, I then create a list of things the project needs to deliver to meet those goals and specify when and how to deliver each item.

I add these deliverables to the project plan with an estimated delivery date. I helps me establish more accurate delivery dates during the scheduling phase, which is what I do next. I then create a list of tasks that need to be carried out for each deliverable identified. For each task determine the amount of effort (hours or days) required for completing the task and the resource who will carry out the task. 

Once I have established the amount of effort for each task, I work out the effort required for each deliverable, and an accurate delivery date. This allows me to update the deliverable section with the more precise delivery dates and create the schedule using Microsoft Project. 

I have noticed at this point when you have an imposed delivery deadline from the sponsor that it is not realistic based on estimates. So I tend to either renegotiate the deadline (project delay), employ additional resources (increased cost) or reduce the scope of the project (less delivered). Which option I go with depends on overall stakeholder agreement and then I update the project schedule. 

The next is the plans. For the resource plans Identify, by name, the individuals and organisations with a leading role in the project. For each, I describe their roles and responsibilities on the project. I specify the number and type of people needed to carry out the project. For each resource I detail start dates, the estimated duration and the method for obtaining them. 

For a communication plan I create a document showing who is to be kept informed about the project and how they will receive the information. The most common mechanism is a weekly or monthly status report, describing how the project is performing, milestones achieved and the work I've planned for the next period. Risks are tracked using a simple risk log. Each risk I have identified is added to the risk log and any associated mitigation. This is reviewed on a regular basis, adding new risks as they occur during the life of the project.

The Importance of Governance

Governance is the ability to clearly define roles, responsibilities and accountability and establish controls and approval routes appropriate to each stage of the project to monitor project progress and compliance.

To ensure a robust governance model for all my projects I put the following in place. I require every project to have a sponsor and this sponsor is appointed during the very early days of the project. They responsible for the business case. When the project is approved they are also responsible for finding the resources and setting the vision for the team.

There also needs to be a project-plan, all my projects require this and that’s more than a Gantt chart. The project management plan is the responsibility myself, although everyone in the team will end up having input to it.  It’s made up of lots of sub-plans that cover how my approach to manage quality, risk, change, resources, so it’s the foundations for the governance and structure for the work.

I also ensure clear defined reporting as an important governance element because it’s reports that tell the Steering Group what is going on. As the key decision-making group, they need enough information to be able to make the right decisions without being bogged down in the detail.

My projects also require stakeholders to be engaged, anyone affected by, participating in or impacted by the project.

I have found that without having stakeholders who are actively participating you might miss issues. When I have engaged stakeholders, they are willing to raise problems and they do the actions that are assigned to them. I also ensure that I am managing lessons learnt– not just capture them in a post-implementation document and then file them away where no other project managers can find them. I have found that lessons learned feed into governance because it shows you have a culture of continuous improvement.  Having embedded lessons learned can be a large change to the culture if it isn't done already but sharing lessons between projects is a good way to improve the culture of delivery and project governance overall.

There needs to be clear roles and responsibilities defined in my projects, I have taken on projects midway where, poorly defined roles and responsibilities on the project team results in miscommunication and duplicating effort because you don’t know who to talk to and you might end up doing a task that someone else believes is their job.

Having unclear responsibilities mean than no one really gets on with anything and the project stalls as no one knows who is supposed to be doing what. To counter this I have implemented a Terms of Reference for the project or include a section on roles and responsibilities for the team members in the project initiation document (PID). Also knowing when to stop a project is good part of governance

I have found that projects should be stopped when they can no longer be justified. That’s the point of gate reviews (or stage reviews). I and the sponsor review the project’s progress and what it can now realistically achieve against the stated benefits in the business case and make the decision: is it worth carrying on?

Stakeholder Engagement - ensure they care

Stakeholder Engagement is the ability to systematically identify, analyse and communicate with stakeholders, using appropriate channels, to ensure all those impacted by the change are engaged, taking account of their levels of influence and particular interests.

The approach I take to Stakeholder engagement is agile and tailored to an organisation and type of project that I am undertaking. 

Firstly I identify and prioritise the key stakeholders. In certain projects the stakeholder base could be extremely wide, whether I'm working on a one-off project or continuously evolving strategies. Understanding who will be affected, how much influence they have and their level of interest is normally my task.

A senior executive may have relatively low interest in a particular project, but their buy-in is crucial to its success. Similarly, junior staff may be very interested in upcoming changes that affect their day-to-day job, even if they have limited power to influence the process.  Prioritising internal stakeholders enables me to focus my energy and engagement efforts on the individuals with the biggest impact. I use stakeholder mapping tools and applications to assist me with these.  I try and then understand and align stakeholder expectations

You can't please everybody all of the time, so you'll no doubt be thinking "easier said than done" when trying to align stakeholder expectations. Nevertheless, in my experience, any project, strategy or activity will run more smoothly if you can get everyone more or less on the same page. This requires exploratory conversations with key stakeholders and transparency regarding the hows, whats, whys and whens of your proposals. Frequent communication is important, as a particular stakeholder's influence and interest in an issue or project can shift quickly.

Again, I prioritise the expectations of the most important stakeholders when aligning the engagement and management strategy.   I try to proactively resolve disputes, there will always be hiccups with stakeholder engagement, regardless of how extensively I've mapped the process. Learning dispute resolution skills helped me mitigate any problems that arise.  The first step is fairly easy but often ignored: listen. An effective technique is to reflect a stakeholder's comments back to them to show you've heard and understood their concerns. For example, you may say: "Just to clarify, you're unhappy because [insert their reason in your own words]."

I also provide a forum for dispute resolution where stakeholders can air their grievances and discuss mutually agreeable solutions. A moderator may be required to ensure everything remains civil and the meeting stays on track.

I tend to also speak plainly, corporate governance is often steeped in jargon. Regardless of job role, whether an internal auditor, compliance officer, in-house lawyer or other governance professional, there will be familiarity with the technical and regulatory terminology specific to the role. However, I don't expect internal stakeholders to have the same level of knowledge. This is particularly important with key board influencers, who may wield significant power and will be hesitant to give the thumbs-up to anything they don't understand.  In my experience, one of the most difficult skills to learn is delivering bad news without obscuring the details. Transparency is often the best policy, although diplomacy rarely goes amiss.

Risk and Issue Management - 99 Problems and a Risk aint one?

Risk & Issue Management is the ability to systematically identify and monitor risks & issues, planning how to mitigate / respond to those risks and issues and implementing the responses.

For issues in projects I use an issues log, I find that issue management in a project begins with a plan that defines activities and business rules to manage and control issues that arise during a project. I tend to catergorise my issues into 4 types;

Major Problem: one that could impede progress or the successful completion of the project and requires immediate attention.

Opportunity: not all issues are bad, some can offer an unforeseen opportunity.

Concern: is not a major problem, but it’s something you want to stay aware of, because it could develop into something that requires attention.

Situation: is another issue that might be a concern or a major problem, but develops from a situational standpoint.

Unlike risk, an issue is not a potential problem, it is happening in the here and now. When I mange issues, I find it is no different than managing a project in that it requires a process and a plan to implement the strategy. I tend to have some approaches to control issues as they arise my projects. I create an issue register to record all the issues. I ensure reporting of issues is prompt so all related stakeholders are aware. I communicate ensure people know who can log issues and that they do so. If there isn’t someone who logs the issue, then you are going to have issues falling through the cracks. That makes more cracks in your project until it eventually just falls apart. I keep a detailed record of this process. Once issue is logged, I assign actions, monitor, assess the impact and discuss with the project stake holders on the approved resolution. Once resolved the issue is closed out officially.

I tend to follow a five step approach to risk management.

First is the risk management planning, here the initial work performed to identify the risk management approach to be used on the project and the specific assessment criteria.

Second, I use risk Identification where I identify the potential sources of risks both initially and on an ongoing basis. 

Third, I carry out an assessment of the risk, where I assess the risks against the criteria 

Fourth, I identify the risk response strategy (ies) that will be used and the detailed risk response plan(s) (what will be done or not done) for each risk identified. This planning includes identifying the trigger event that will cause the risk response plan to be executed. 

Lastly, monitor and control for a risk event occurrence, reassessing the risk (likelihood and consequence) and monitoring the performance of the risk response plan and reporting the results.

Thanks for reading, If you feel that there might be areas where I can assist your orgnaisation with feel free to drop me a message here on Linkedin or email me at [email protected]