Tips for kicking off a project

Hi all,

Sorry for the long hiatus in blogging.

I went on holiday for a couple weeks. Came back and have been busy at work ever since, particularly looking to stand up a new project that is particular large and very complex.

We recommence the blog with tips to starting new projects a project manager

1. Know The Scope

Obvious one really and the reasons why.  As a Project Manager you need to know the scope like the back of your hand.  It will be expected that you know and understand the scope.

• It will allow you to have conversations with project team members whether that be about planning, progress, troubleshooting, risk mitigation etc.

• It instills confidence, if you sound like you know what your saying then you probably do! You will instill confidence and gain the trust of others.
• You know your role and how it contributes. It could be that your project sits within a wider program, you need to be clear on the benefits delivered to the program so you can ensure the project is successful.
• Mitigate scope creep.  Knowing the scope like the back of your hand should allow you to identify scope creep early and take the approach action.

2. Set Expectations Early

Be honest and truthful about any expectations you need to set.  Don’t sugar coat any challenges or ignore problems, from the off.  It’s easier to set expectations early and improve upon them later.

• Honesty is the best policy. Be honest on what can be delivered in the timescales. The old adage, under promise and over deliver.
• Others will likely have the same expectations.  Don’t sugar coat it, others could be expecting challenges too, and won’t be appreciate being bullsh**ed to.
• Communicate early.  Make sure you set expectations early, it’s harder to expectation later in the project.  Also stakeholders make commitments based on the expectation set.
• Target your communications/expectation set.  Set what you feel are the right expectations to the right people, you don’t need to bombard everyone with the project.

3. Identify Risks and Issues early.

Like expectations these need to be identified early to allow time for suitable mitigation actions can be identified and executed.

• Agree consistent approach with risks.  So that there is consistency with risk scoring and impact to business but also standard language, use Risk statements if necessary (eg. IF, THEN, RESULTING IN)
• Flag any issues early.  Like expectations these need to be flagged up to the right level (e.g. project board) as soon as they hit, the later you leave it the less time you have to mitigate.
• Flag any Red risks early, like issues these need to be flagged up to the right level for a decision to be taken on the approach, accept the risk, mitigate, which mitigation option?
• Knowing your risks early allows you to plan.  Mitigation strategy maybe to accelerate or move elements of the project around.

.4. Know the plan

A Project manager is expected to know the plan, it is afterall their plan.  It doesnt have to be to the nth degree, at least know the stages, key dates and critical path.

• Knowing the plan instills confidence.
• Knowing the plan allows for conversations around risks / issues as they arise
• Knowing the plan allows the PM to impact assess issues, change requests etc early.
• Knowing the plan, should mean you are actively communicating the plan to all stakeholders through conversations.

5. Know your team

Who are your team, do you have work package leads, full time or part time resources.  Are their strong personalities and political considerations to be taken?

• Knowing the team helps to resource the plan accordingly, identify the gaps in the plan and resourcing risks
• Knowing the team helps to keep them happy, how are you going to interact, does the team like to be left alone or feel included, spend some social time together.
• Knowing the team allows you to identify the best communications method to bring the team together and the appropriate forums.  Some members may not like each other.  Keep them separate if you can!
• Knowing the team may identify any personal considerations you need to make, do they have holiday, illness within the family or commitments outside of work they need to stick to.
• Knowing the team will allow you to engage at an individual level, a good PM is a good people manager, you will need favours.

6. Define the communications plan

So many projects fail because people do not talk.  Projects fail to setup any formal communications plans or at the right level.

• Setup workstream communications, each workstream should have it’s own meetings.
• Setup workstream  / work package lead meetings, they need to talk across the workstreams. Provide updates to each other and agree on project direction, there will be dependencies between streams.
• Setup planning meetings, is the project on track, new changes need to be incorporated into the plan
• Setup risk meetings, opportunity for workstream leads to identify new risks and issues, but also review old ones.
• Setup PM to PM meetings, if you’re working with other PMs (including customer) setup meetings for one to one time
• Setup Project steering groups with key Business and Technical stakeholders to review progress and items to be flagged to the board.
• Setup Project board with senior user, supplier, sponsor for decision making
• Even if the meetings are 30 minutes, at least you are securing time from resources to talk to each other and to work on your project.
• Be pragmatic, not every project needs the above level of communication.  Go for what feels right, you can always add or remove later.

7. Document

Document the agreed project approach in whatever format, PID, Brief, Mandate, Charter etc.  Make sure it’s agreed between the workstream leads, PMs and Project Board.

It sets expectations earlier and gets everyone signed up to approach.

If not you could find yourself writing the PID at the end of the project, like I did with my first ever project…. !

 

See ya next week

Thanks

William

It’s a Risky Business

Hello everyone, apologies for the lack of blogs I’ve spent the last two weeks on holiday.   Back now to the real world of work and a bit of light blogging. This week’s topic is the world of Risk.

As a Project Manager I’ve spent a lot of time identifying and mitigating risk, prior to ascending to the rank of Project Manager I was a full time Risk Practioner on a large, complex programme, supporting the definition and mitigation of risk.

What is a Risk?

Risk is an event, or scenario that if it materialises could impact the project.  Impact could be increased costs, duration, scope, decreased quality, a combination of all four or another factor that could negatively impact the project.

For example a risk to a construction project is the delivery of construction materials, there is a risk that they would not be delivered in line with the construction timetable, missing the project delivery dates.

Risks are mitigation through a series of agreed actions within the project, with the aim to reduce either the impact or probability of the risk occuring.

Defining risk – Risk Statement

Before defining the mitigation strategy the risk must be defined in as much detail as possible, otherwise how do you know what to mitigate.

First the Risk must be articulated as a “Risk Statement”.  The method to construct the risk statement must be the same across the project or programme to ensure consistency.  My personal preference is to use IF, THEN, RESULTING IN.

Taking our previous construction risk as an example;

IF Construction Materials are not delivered in line with project timescales

THEN Construction team will not be able to complete their tasks in line with project timescales

RESULTING IN Project will miss it’s agreed deadlines

Defining risk – Impact

Once the risk statement is firm and agreed within the project team the impact (Risk Score) can be articulated.  Using three point estimating (worst case, most likely, best case) to define probability and impact (cost, time or quality) you can determine the impact.  I would simply ask the team for their estimates and go with the average for the three point estimates.

If you have agree milestones (Payments, liabilities etc) you can use these for the impact.

The probability multiplied by the impact will give you the risk score.  It can take it further and RAG (Red, Amber and Green) the score accordingly in line with your business risk appetite.   Again I would suggest coming up with an agreed scale to ensure consistency across the business.

Risk Mitigation

Risk mitigation is either to reduce the probability or impact of the risk or eliminate completely, through a set of actions. Which could incur a cost, monetary or time.

Our friend the construction risk could be mitigiated by ensuring the suppliers are aware of the timetable, but also the implications of late delivery.  They would also need to be updated with any changes to the schedule. 

It could be further mitigated by receiving early deliver of supplies, but storing locally.  Which would incur a storage cost, but this cost could be less than the impact of the risk materialising.

Alternatively you could pass the risk to the suppliers, by ensuring there are penalties for late delivery or they are liable for any losses incurred for late delivery. 

Passing ownership of the risk is always the preference as there is no exposure to the business or project.   

Risks becoming issues

If a risk materializes, then it’s known as an issue – something that immediately impacts the project.  As part of the risk mitigation a fallback plan should have been identified that seeks to reduce the impact.

In our example of late delivered materials, one fallback could be to work on another area of the project, or to seek the supplies from another supplier.

Summary

Risks are a part of every project whether you like or not.

Risks are mitigated as part of project activities anyway, regardless of whether there is any formal risk management occurring.  For small projects you can get away without active risk management, for medium to large or complex projects risk management is a must.

It’s easy to plan for the things that you need to do, but actually you need to watch out for the things that you haven’t planned for.

 

 

Requirements Gathering Governance

Working this week on customer site to gather project requirements, our focus has been on the technical and business requirements, driving towards design and hopefully signoff.

The architect has been leading with the technical requirements, against a template we use internally.   But in actuality he’s been capturing the current solution for the customer but not the future plans, as none of the stakeholders in the requirements sessions has a view as to what the future holds or if they do have a view of the future requirements, they’re not empowered to make a decision on the requirements.  Something we discovered after each session.

Added to this there are a lot of customer stakeholders, with no governance from the customer – no one overseeing the conversations with having with the different teams.

This is making life difficult as no-one within the customer’s organisation is taking responsibility for requirements governance, as requirements drive design they are therefore are not actively involved in the design decisions.

Not ideal if you’re ultimately seeking design signoff from the customer!

However it seems that the customer’s expectation is we’ll provide all the answers and they don’t need to be involved.  Which could work, the risk is that the customer will reject our proposed design.  To mitigate we’re starting a series of design workshops, which will effectively bring the senior technical stakeholders on the customer side, give our chance to present the requirements (current operating state) and the new world proposed, but also the benefits it’ll provide. 

My feeling is because there is no “requirements gathering” governance, we’ll burn more time covering old ground,  but ultimately needs to be done.

But I wonder, if there’s an approved methodology to gather requirements.  With the right level of governance that ensures involvement from all teams.  Something i’ll ponder and happy to hear feedback on.

PMI Post : Tips for First Time Global Project Management

Three solid tips for those engaging in Global Projects

http://blogs.pmi.org/blog/voices_on_project_management/2013/08/tips-for-first-time-global-pro.html

 

RAG IT

 

A couple weeks ago I was tasked by boss to look at our RAG report template and come up with a better one, simply because I said I didn’t like the one we currently had.

For the uninitiated a RAG Report is a Red (R), Amber (A), Green (G) Report.  A project report that is issued with regular frequency to all stakeholders, internal / external or a mix depending on a project.  With the primary purpose being to educate and inform stakeholders on the project status, whether it is Red, Amber or Green against it’s goals and progress.  The secondary purpose maybe to seek additional support from the executive sponsor of the project, by articulating the issue and required response in the report – this of course depends on the organisation and it’s approach to escalations.

RAG report is sometimes known by other names, for example i’ve heard other organizations call them Highlight report or FLASH reports.  For the purposes of this Blog, we’ll call them RAG reports.

I’ve been thinking, what makes a good RAG report? What inputs, contributions, formats, level of detail is required.

Obviously whether the project is Green, Amber or Red (RAG Status), should be immediately obvious to any reader. That’s given.  RAG status should be one of the first items on the report, near the top.  So that if the reader has many reports to read they can focus on the Amber and Red projects, ignoring the Greens – as each Green project will simply state “on track”.  From a formatting point of view there should be a colour indicator that reflects the RAG, allowing the reader to quickly focus or move on as required.

Some argue that for each area of the project (Schedule, Finance, Risk, Resource, Security, Budget etc) should have it’s own RAG status.  I feel this confuses things and adds very little value and is covering by the RAG status and description (below).

 

Alongside the RAG Status there should be what I would call a RAG description – Why is the Project Red, Amber or Green.  If it’s Red or Amber, what are the corrective actions to move the project back to Green, or what assistance from the executive team do you require.  A paragraph or two is sufficient to cover this section.

Project milestones should also be listed within the RAG report, with the baseline (original forecast date) and current planned (or achieved) dates.  To demonstrate where the project is against original plan.  If you have a project budget this should also be listed, with baseline, actual and expected cost at completion.

OK so far we’ve listed what the project is doing, it’s status, it’s progress against original plan and budget.   The RAG report should also flag any Amber or Red risks, again it’s not worth listing green risks as these either should not materialise or have an impact on the project.  

These Risks should be articulated in a Risk Statement (IF, THEN, RESULTING IN), with impacts, time of impact and response action (Mitigate, Accept, Fallback etc).  With a short summary of the risk response actions and who owns them.  If you have a lot of Red and Amber risks, i’d limit these to the top ten risks by impact to the project or by your own scoring mechanism.

Alongside and before risk, any issues should also be listed. All issues should be listed, again unless you have a lot and in that case I suggest you keep it to the top ten by impact or score.

Key project dependencies could also be listed, but I list them as milestones within the project. As they should be milestones anyway, listed both milestones and Key dependencies seems like duplication.

In terms of format, it’s a personal choice.  I like spreadsheets as you can customise the layout easily and also save them as PDFs, before distribution.   I’ve also seen PowerPoint and Word RAG reports.  The choice is yours and whatever suits you and your organisation.

In summary the RAG report should be short and snappy, that someone outside the project team can pick up and understand the status of the project, and whether they need to do something of about it.  If you can stick to one page then great, if not, put the summary on the first page and the detail on the second, for those who are interested.

 

 

 

I PROJECT MANAGE – THEREFORE – IAM

During a conversation with a fellow Project Manager this week, an interesting philosophical question came about.

 

We were discussing the value a PM can add to our business.  He has more experience within the organisation, I have more experience as a PM.  As a result, two different outlooks on the value of a Project Manager.

Towards the end of the debate I stated that sometimes I struggle to see and understand the value of PM.  To which he replied, me too! 

 

OK so you’re probably thinking that it’s not good not to understand your own professional purpose and value, and I agree.  But hear me out.

 

In our organisation projects and activities run without formal project management, everyone does their job and if you like “project manages” their own area of responsibility.  This has been the case for a long time, and it works really well.  In this scenario, with known quantities, processes, low complexity and low risk a Project Manager is surely not required.   To add to this we’re not technical proficient and could not complete the build of services to the customer.  In this BAU / Small Project Scenario a Project Manager will just burden the team with unnecessary tasks, meeting and generally be a nuisance.

 

So WHERE can a Project Manager add value.  Let’s delve into what a PM does first before locating value add.

 

The role of a PM is to plan the project, corral and co-ordinate resources, communicate with the team and wider organisation, identifying and mitigating risk and control the project.  Pretty obvious stuff right, and I’d also say this is the minimum expectation of the role, more like project co-ordination.

 

A good PM should also the project champion, the project is his/her’s baby to deliver into the world, fit and healthy.   The PM has total responsibility, ownership and passion for the project.   They should be challenging all aspects of the project – processes, timescales, plans, people, to improve on project timescales or at least reduce risk profile to minimum but also fighting their corner for shared resources, resolving issues and escalating to the right people for assistance as needed.

 

Now we know what a PM does, or should do, we should have an idea as to where the PM can value right ?

 

I think so.  PM’s should be involved to deliver complex, non-standard, prestigious, business critical projects.  Examples could be projects that have never been attempted before with new technologies or customers, it could even be a project with standard deliverables within the organisation but with high risk or accelerated timescales.  In these instances the PM comes in, plans, executes, controls and closes down. This is the value add. 

In summation the PM should be involved in the weird, the wacky, the complex, the business critical project.  That’s not to say they shouldn’t work on the projects that the business would consider standard.  Just that more value can be added to the non-standard.

 

Thanks

William

 

PS Phew! First real blog out of the way, next one coming Friday next week.

Hello World

Well here we are.  After many years of thinking “I should spend time working on extra-circular activities, that will broaden my mind and hopefully others”,  I’ve decided to take the plunge into the world of Blogging.  Hoping that this blog will provide the outlet I’ve been looking for.

The objectives of the blog are the aforementioned expansion of my mind, sharing mine and others thoughts (links and quotes) on this blog.  

But wait, I hear you ask, what’s this blog about?

Good question and obviously like most blogs this is about me.  So the real question who is me? What am I, what do I do, what drives me?  These are all deep philosophical questions that actually have a really easy (and some may say boring!) answer.

I’m William and I’m an IT Project Manager (said in AA meeting style voice).  I’ve been an IT project manager since 2008, five year’s experience which is the magic number to start receiving some credibility within the IT Industry that you know IT and you know Project Management.

 

During those five years I’ve worked for three different companies.  One large Multinational (200,000+ employees) and two smaller Multinationals (5,000 employees).  I’ve enjoyed my time at each, but currently enjoying my stay at the third organisation the most as the Culture is strong, with a focus on the customer outcome and not being afraid to challenge the internal processes that may affect that.   Which as project manager really chimes with my belief that any problem can be overcome and that the ultimate goal is meeting the customers objectives, it’s the simple formula of Happy Customers = More Business.

That’s a brief summary of me, hopefully I’m not too boring and you never know – no-one may ever read this blog.   To be honest it’s fine if no-one apart from  me reads this blog,  as the primary objective is for me to have this creative outlet that is tempered, contextualised and constrained by the realities of the glory IT Project Management.

 

I’ll be updating the blog every Friday and ad-hoc with any juicy snippets that spring to mind or I feel free to share.

William