Skip to main content

Tag: PRINCE2

How to make your manager pay for your project management certification

Achieving a globally-recognised project management certification will improve your ability to lead successful projects.

But it’s not always easy to get certified independently, especially when juggling your career, family and social life. Good training can be expensive too and financial restrictions may be stopping you from building the skills you need.

For most of us, a helping hand from your organisation could make all the difference in achieving a project management certification. Unfortunately, it can be tough to convince your manager to pay for your training.

There are some steps you can take to get the certification you need, without paying out of your pocket. Here’s how to make your manager pay for your project management certification.

1. Explain why it’s in your manager’s interest

It’s ultimately in your manager’s best interest for you to get qualified. Put simply, the better your project management skills, the more you can contribute to the business.

1 in 6 projects overspend by a massive 200%, according to a study by the Harvard Business Review. It’s clear: employees with expert project management knowledge will save money across every project.

For example, becoming a PRINCE2 Practitioner encourages continuous improvement across project management practices. Over time, your projects will become more successful, yielding cost-savings for your business.

Alternatively, achieving the PMP certification will teach you tried-and-tested project management techniques. For over 30 years the best project managers across the world have collaborated to create a body of knowledge which is then taught through the PMP certification.

2. You’ll bring clarity to your projects

Project management certifications bring clarify to your projects by providing tried-and-tested frameworks and methodologies in which to manage projects efficiently. Your projects will benefit from a common and consistent approach that your stakeholders will take confidence in.

For example, the PRINCE2 Foundation and Practitioner certification provides its students with a standardised system for project management, allowing you to provide accurate reports to your project’s stakeholders, without relying on bureaucracy.

Certification is one of the best ways of adopting a project management methodology in your business and the sooner you do, the better.

3. Clients value certification

If you’re working with external clients, or even delivering projects internally, managing successful projects will help preserve your key client relationships.

It’s well worth considering your organisations wider business goals. Are you bidding on large projects, or plan to in the future? If so, you can assume other organisations will be showing off the credentials of their project managers. Pointing out this disadvantage could help your manager see the bigger picture value of your training and certification.

4. Build your case for training

Once you’ve decided you need the training to improve your job performance, it’s time to build your case for training.

Show your manager that you’re committed to undertaking the training by doing thorough research. Avoid focusing on just one training provider, instead show evidence that you’ve researched numerous certifications and courses.


Advertisement
[widget id=”custom_html-68″]

5. Ask at the right time

Time can be a crucial factor when making the case for training. Your boss may want to discuss your proposition in detail, so making sure you have their complete attention is critical.

Consider raising the topic of certification at your performance review. You should already be discussing your professional development at your performance review, so it’s an ideal time to raise your request, while explaining why the training would improve your performance.

It’s also worth considering your team’s training budget, and when it is released. Raising your request early, before the budget is swallowed up later in the year will make it more likely to be accepted.

An alternative strategy is to make your request when you’re training budget is set to expire. Within enterprises or large organisations, departments will often leave money on the table by not utilising their full periodic training allotments. Timing your request towards when you’re training budget is set to expire could strengthen your position.

Another good time to achieve your project management certification is in-between projects. This is an opportunity to highlight tools and methods you may not have used in your last project, and how you’ll be in a better position to tackle your next project from the start.

If waiting is not an option, there’s no need to ambush your boss in person. Craft a compelling email that explains why you need certification first and then negotiate it in person afterwards. This way you have two chances to negotiate and more time to convince your boss.

6. Research different training providers

You get what you pay for when it comes to training and certification. Cheaper training may not utilise official curriculum or instructors and training days may be spread over weeks or months.

If your organisation requires you in the office, consider intensive or boot camp style training which aims to get students skilled and certified, with minimal time out of the office.

Krishna Williams, Senior Consultant at Firebrand Training, says: “I’ve found it essential to communicate the value of boot camp training upfront. The longer your staff are out of the office, the less time they’ll spend progressing critical projects. This will almost always cost the organisation more in the long term.”

You should also consider when the best time is to attend the training. If your manager can’t lose you for several days, consider training over the weekend.

Your boss might still flinch at you being out of the office for any amount of time, but with smart planning, training over the weekend will minimise this friction. By sacrificing your weekend you’ll also prove your commitment to improving your skills.

Take note of where your training provider is based and what travel expenses you may incur. It’s not wise to surprise your manager with an extra bill, so have every cost itemised and ready before you make your case.

7. Consider your team

If you manage other people, this is a good time to consider whether they should also receive training. This will show you’re not just after the certification to progress your career, but also care about the business benefits.

Cost-savings can be gained by training multiple members of staff at once. If your team needs training, it may be cheaper and easier to organise private or on-site training which can offer savings over public courses.

8. You don’t need a week off work

Many project management certifications can be achieved quickly. For example, PRINCE2 certifications are quick to complete, ranging from 20-50 hours for the Foundation level.

And, if you’re looking to get qualified fast, there are a number of training providers that will bundle multiple certifications with the exams included.

What are you waiting for?

To secure funds for your project management certification you’ll first have to demonstrate the value of the certification. Following these simple steps will go a long way in ensuring that you receive this important training with the support of your business.

5 Effective Project Management Methodologies and How to Apply Them

It’s no secret that in the project management industry, project failure is a recurrent problem.

Complex in origin, prevalent project failure can be attributed to many different sources, from companies enforcing overly optimistic project deadlines to inadequate project management.

As a project manager, there isn’t much you can do to change the outside factors affecting your project, but you can mitigate their effects on your project, and give your project the best chance of success through proper project management.

An effective method to streamline and structure your project management processes is by following a formal project management methodology. A Project Management methodology is essentially a model that Project Managers follow for the design, planning, and implementation of their projects. There isn’t one ‘best’ project management methodology to use as each of them comes with their advantages and disadvantages.

The worst thing any Project Manager can do is become too complacent in a single project management methodology and try to apply that same methodology to every project. Often project management methodologies are as idiosyncratic as each project and trying to force your favorite methodology onto every project, just because you’ve had a row of successes with it, can be as much of a recipe for disaster as not using a methodology at all.

It’s wise that in the planning stages of your project, to thoroughly assess the relative merits of each methodology against the requirements and objectives your project. Adaptability is a core competency for any project manager, even if a methodology doesn’t suit your project exactly, many are flexible enough to adapt to a specific project and project team.

Following is the list of the five most popular project management methodologies used today, and when they are most effective.

Waterfall Project Management

Waterfall project management is one of the more traditional project management methodologies. Utilizing a structure that fits its name, waterfall project management follows things through sequentially, beginning with the concept all the way from project inception to completion and conservation. As such, the project requirements defined at the outset often bear little or no alteration.

Waterfall methodology is most often applied to large software development projects as thorough planning and predictability are paramount to the project process and success.

Agile Project Management

Agile and Waterfall are at the opposite ends of the project management methodology spectrum. Whereas waterfall is sequential and predictable, agile project management works on the premise of adaptability and reacting to regular feedback whether from a client or team member.

Agile project management is best utilized when a project requires constant input from the client or management, as this often results in flexible requirements and role responsibilities. It’s most popular with smaller projects or projects with fast paced development schedules.

Critical Chain Project Management

In opposition to both Waterfall and Agile Project Management, Critical Chain Project Management focuses more on rectifying resource problems. As part of Critical Chain Project Management, each project is deconstructed into a core set of elements that create a project timeline. Within this timeline, it is made sure that enough resources are allocated to the critical chain, as well as simultaneously splitting the remaining resources to other tasks to ensure they can operate parallel, and ensuring that there are still enough resources left over in case reassignment is necessary.

Critical chain is useful for teams that either has plenty of resources or enough flexibility within their team’s skill sets to allow a resource driven project plan.

PRiSM

Project management is never one to shy away from a good acronym, and PRiSM is one of the most well-known. Meaning, when broken down, Projects integrating Sustainable Methods, PRiSM was developed by GPM Global to create a sustainably driven methodology that could adequately consider environmental factors, as well as act as an efficient, large-scale, project structure.

Unique, as it is one of the only project management methodologies that requires accreditations, PRiSM is largely used within real estate development or construction projects that may be problematic for the environment it is situated within.

PRINCE2

PRINCE2 is touted as a government endorsed project management methodology and is used as the industry standard across much of the private and public sector in the UK and beyond. PRINCE2, is one of the only other methodologies, alongside PriSM, which requires certification. However, PRINCE2 offers a multitude of courses that are scalable to both your experience and the level of organization the project requires.

Extremely process oriented, requiring each stage of the project to follow its plan and system of processes, PRINCE2 is one of the most complex, yet thorough, methodologies. Due to its vast approach, and its focus on building a range of strong project management skills and applications, PRINCE2 is workable in the majority of project situations.

The 10 Most Common Project Management Mistakes and How to Avoid Them

If you find yourself repeatedly failing to meet essential project deadlines or KPI’s, you might be making one, or more, of these very common project management mistakes.

Making an error in the workplace is inevitable. In fact, there’s a high probability many of us have made the same mistakes, and while at the time it can feel like an utter disaster it is the ability to recoup and learn from our failures that ultimately makes us better at our jobs.

Unfortunately, as project managers, even our smallest mistakes can have much larger implications further down the line, sending us over budget and past deadlines. Although each project will have its complex set of issues unique to it alone, across the industry there are some predictable and recurring factors we can address, that often doom a project to failure before it is gotten off the ground.

1. Assigning the Wrong Person to Lead the Project

Too often candidates are determined to lead projects due to factors other than their suitability or experience. Not that a lack of workplace experience cannot be made up of other factors, but taking charge of running a project is a difficult task, and often requires specific experiential skills or knowledge.

While it is true that skilled managers can lead across subject matters, for large scale projects with complex attributes, a greater number of team members, or a targeted technical knowledge requirement, it is much better to source the most experienced leader, rather than just the one who’s available.

Place as large a focus on assigning the correct manager for the job as you usually do to allocate resources, and place a higher priority on choosing a manager whose skill set more closely matches the project requirements.

2. Lack of Communication

Communication is essential in every relationship, but never more so than when between you and your project team. Not communicating properly, or at all, with your team and client, is one of the quickest ways to send your project to the grave.

By creating a culture of open communication, and setting out some simple communication strategies from the outset, such as regular check-ins and deliverable reviews, you and your team will have a clear view on your projects progression, and be able to proactively spot and resolve any issues coming up on the horizon.

Similarly, by engaging better with your team, you can keep your client in the loop with real-time project updates and avoid the awkward due date deliverable talk.

3. Mismanaging Team Members Skillsets

As important as it is to choose the right leader for the project, it is equally as important to choose the right team members and to take the time to understand exactly how their particular skillsets will fit into the larger scope of your project.

An excellent project manager analyses the project needs and utilizes his team in agreement with their strongest attributes.

If you do not have the luxury of handpicking a team to suit the project, then be sure to you sit down with your team before you begin and discuss their experience and competencies. Don’t be afraid to get specific. It is not enough to just know one of your team members has experience in web developing, filter out their specific disciplinary strengths and weaknesses and optimize their workload accordingly.

4. Too Broad a Scope

Anyone who’s been in the business long enough has experienced a project with a scope that appears to increase continually, while the price remains stagnant. Although this kind of scope creep where the project focus changes continuously over the length of the project should be in no way viewed as an inevitable part of the project process.

Scope creep often happens when the real outcome of the project is misunderstood by or is not consistent with the client, management, and the project team. This is why developing a clear scope statement at the outset of your project is so important.

A carefully thought out scope statement should include a clear and firm definition of the project goal, deliverables, what is both “in” and “out” of scope, and project constraints. Simultaneously, you must develop a system of strict, universal and well-documented approval processes so that any subsequent changes to scope, budget, schedule, resources, and risk are vetted and approved.

The scope statement should regularly be referred to for making future project decisions, and outlining a shared understanding of the project, and should never be created in isolation, but instead with the input of your entire team. Not only will they have knowledge, experience and valuable insights, but they will then be more aware of how and when to implement the process throughout the project

While it is true that project scope must have some degree of malleability placing checks and balances against changing any aspect of the scope allows you to make more considered decisions and control of rampant scope creep.

5. Over-Optimistic Scheduling

The importance of creating a realistic schedule for your team, and the project, cannot be understated.

It is too easy to create an over-optimistic schedule designed to impress the client but is completely infeasible. Not only is the probability of finishing the project with an acceptable, quality product very unlikely, but attempts to meet these dates will cause unnecessary stress for both you and your team, schedules to slip and throw your whole project out of whack.

The project schedule directs the project team on the what and when of their actions. For your client, it projects significant milestones and the due date of key deliverables, as such, it is important that you treat the creation of your schedule as a collaborative effort.

By checking in with your team on project effort and time estimates, and your clients own schedule, you can strike a compromise by which to meet your client’s expectations, and your team has the breathing room to finish the project to a high quality.

6. Lack of Detail in the Project Plan

A project plan is one of the essential elements of a successful project outcome, yet the most misunderstood when it comes to project management.

A project plan does not just mean ‘project timeline.’ While an expected chronology of your project is a major component of your plan, a project plan requires a much deeper level of information regarding all elements necessary to the planning process from the specification of the new project to the budget, schedule, and quality metrics.

When done correctly, a project plan acts your very own route planner. By providing insufficient detail in your project plan, you are not only opening your team for confusion about the full requirements of their time or tasks but leaving yourself without clearly defined metrics to measure the success of your project and management strategies.

Take the time before you start your project to identify all the activities and related tasks required to meet the project’s scope statement successfully and all your project deliverables including the estimated time duration and the assignment of a resource that will be held responsible for completing each task. Keep in mind, that the plan you make at the start may not be the one you finish with, but learning to create a clear project plan and knowing how to discuss its key components is crucial to your project’s success.

7. Not Recognizing Your Team’s Successes

Team morale and productivity go hand in hand, and refusing to recognize your team’s successes, often has a detrimental effect on both. Sometimes it is too easy to focus on the end game, metrics, and numbers, and forget the employee that pushed them to success.

The small successes, the short-term objectives, and daily goals, any extra effort to contribute to advancing the team’s mission is, where the individual shines, and should be celebrated.

Develop a performance review system as part of your project management plan, and ensure that performance on projects is measured, reviewed and recognized as equally as it is in their day to day responsibilities.

8. The Wrong Project Structure Used

Project management is not one size fits all, and while you may have had great success with a particular project structure before, it is dangerous to get too comfortable with one approach and ignore each project’s variables.

Let’s take size, project teams with a larger number of individuals, around 8 or above, will find it difficult to report to the same project manager. Just as, you, the project manager will find it overly challenging to maintain communication and follow ups with too many team members reporting directly to you. If parts of the project are undertaken in different regions of the country, communications may suffer from a lack of clarity and jar with the larger project structure.

It is key to assess each project individually and adapt communication strategies and reporting protocols to suit each new approach.

It may be useful to educate yourself and your team in umbrella project management methodologies that teach adaptable, industry standard project structures, so each project structure retains an efficient cohesiveness and familiarity.

9. Being Reactive Instead of Proactive

Your project is running correctly, aligning with your scope and project plan, but then something unexpected comes along and disaster hits. The project gets derailed. Even though you and your team mobilize quickly, identifying the best options and solutions based on experience, you have got no opportunity, nor time, to test these solutions viability. Acting reactively, management by crisis only leaves your project vulnerable to further failure.

Risk Management is the process of identifying, analyzing and responding to risk factors throughout the life of a project, and developing a stable basis for decision making in regards to those risks. A robust risk assessment provides controls for possible future events and is proactive rather than reactive.

While it is impossible to know every likelihood of every potential occurrence, by undertaking a thorough risk assessment before you execute your project plan, and continuously re-focusing that assessment throughout your project, you can reduce the likelihood of a disastrous event occurring, as well as its impact.

10. Being Resistant to Change

Although most this article has been spent pontificating about the importance of preparedness, clarity, and structure, the ability to be flexible and adaptive are qualities intrinsic to your project’s success.

Despite your extensive risk management and project planning, it’s likely the functionality of your project is going to change daily, whether it’s the small things such as missed meetings, employee absence, or a change in direction that requires you to develop a new approach or resource, and being rigid about your processes only ensures that your project is unlikely to see completion.

Being flexible isn’t something you can plan for. Remember that your project is an ongoing process, keep an open mind, and trust that you and your team will be competent enough to come up with a suitable solution.

Project Initiation Documentation – What’s the Point?

Have you ever written a PID (Project Initiation Document)? Did you get any value from it? Did the project?

Is the PID just a bureaucratic process, or is there any value in it? Can we do something different and get more value?

Any project initiation document, or process, will only add value if at least one of the following things is true:

  1. It strengthens the quality of thinking before the project
  2. It gets read by somebody who believes it added value to them
  3. It is used as a reference point, by everyone, and accepted as ‘the standard’ for what is to be done.

Let’s look at these, in reverse order.

1. The PID as a reference point

I have rarely seen project initiation documentation used as a reference point or to hold people to account of an approach, agreement or a deliverable. Where I have seen attempts at this (“In the PID, we said we were going to do it this way”), I have seen easy rebuttals explain the folly of the concept (“but things have changed, and you need to change your approach as a result”). Some would argue that if you keep your PID up to date as things change, it is still valid. I would argue that project teams are terrible at keeping documentation up to date. Let’s stop pretending we are going to do this and find a better way and if the PID is continually updated to reflect reality, is it an initiation document, or just the current view on what we are going to do? Having a current agreed view on where we are going to might be useful. A PID-style document might not be the best way to do this.

What are the alternatives? Personally, I like meeting minutes the most. I like sitting down with the people that might be the readers of a PID and instead, having a discussion. This meeting creates a two-way process open to cross-examination and debate (much more so than a document). Circulating minutes of the outcome keeps a record of what was agreed, and no-one needs to read a dry boring text. As things change, we discuss them again and circulate minutes again. Our documentation is up to date. However, more importantly, the people involved know what is going on rather than interpreting an understanding from a dry document. I find this approach eases understanding (the most important thing) is quicker (project managers like faster) and can be used to hold someone to account (“in the meeting on XYZ date, you said…”).

2. People who read the PID get value from it.

For this to be true, firstly, the right people have to read the PID. That means not only the sponsor or governance functions but project members and other stakeholders. This does not happen. We are kidding ourselves if we think it does. For those that do read the PID, they read the sections that they are interested in or perceive as relevant to them, often missing out important context as a result. That is not to say that some people do not read the PID. Of course, some do. However, it is not read as widely as the information should be disseminated and understood.

For the PID to deliver value, the readers have to understand its contents. The project teams that produce PIDs are often not professional technical writers, and their PIDs are full of ambiguities, contradictions and open to interpretation. It is impossible in this scenario to be certain that the few people who read it, get the value from it that you intended.

Again, that does not mean no-one gets the expected value from reading the PID. It is only fair to assume that sometimes, a percentage of the people that read the PID, get the value intended from reading it. The problem is, that on projects you need everyone on the same page. The people that have read the PID and have interpreted something else, and the people that have not read the PID and have incorrect assumptions and thoughts, are a significant problem.

I do not think the solution to the problem is writing better PIDs. I do not want my project managers to become professional technical writers. I want them to strengthen their project management skills. Given the limited utility in the PID, in adding value to its readers, maybe its time we stopped writing PIDs. Instead, use the first governance meeting to present the PID contents to the governance group, use a project kick-off meeting to do the same to the stakeholders, use the first team meeting to do the same to the project team. Now everyone has the same information. Moreover, you can do this without writing the PID.

3. Strengthening the quality of thinking

If we look at the sections in a traditional PID very few of them, have content which is a foregone conclusion. That means thought (and often discussion, group-ideation, and compromise) are needed to produce the contents. Unless a PID is produced in isolation (which it should not be), it is very hard to argue that the process of producing a PID does not improve the quality of thinking about the project. It evidently does. Hang on! Have we just re-asserted that a PID is useful after spending the last 10 minutes saying the opposite?

The process to produce the PID document is where the thinking happens. The process and discussions add value. However, you do not need to produce the document at the end. The document does not add value. Yes, we need to capture the salient points and disseminate the learning, but a document is not the best way to do that. Instead of writing, think visually. Let’s have schematics and mind maps. Instead of hoping the document is read, let’s present the document. Let’s have more judicious use of meeting minutes as documentation. Let’s stop wasting our time writing PIDs and improve the wider understanding of the project by spending more time managing our projects.

In Summary

The main problems of the PID are that it is not a good communication tool. Written communication should be low on the list on a project, it’s open to misinterpretation and misunderstanding; it takes time to produce. Time that adds little value; (iii) the PID is not read. If it is, it is not read in a way that there is a shared understanding of what the project is going to do; (iv) project teams are bad at documentation and don’t keep it up to date and (v) whilst the process of writing a PID forces some critical thinking about the project that adds value, skipping the PID, does not mean we need to skip those processes too. Instead, maybe we should have the meetings and discussions to create the PID content but present rather than a document, minute rather than read and move quicker rather than spending time writing.

A Surefire Way of Delivering What You Set Out to Deliver In Your Next Project Plan

No amount of detailed planning will guarantee success.

Yes – you read that correctly.

Many project managers tend to think – “I’ve planned the project, worked out when we need to have things done, now just monitor the work and it will all happen.”

No it won’t.

In fact, the only thing you can really guarantee about a plan is that it won’t go to plan.

Related Article: Look Out for “Best Efforts” Projects

I can just hear it now… “Mark – why start with this seemingly contrary aspect of project planning as a way of ensuring I deliver what we set out to deliver?” Simple – it’s to show that you should not spend an undue amount of time getting every little detail right when planning.

In fact, the more detail you attempt to put into a plan, the more likely your project will start to miss targets, start to get behind and generally cause you a lot of angst. So the idea is to find the happy median between too little and too much detail. But how?

What you need is clarity of what it is you want to deliver from the start.

Planning involves the deliberate intent to think about what needs to be done, when, by whom and what dependencies are required before we are part way through – while it is all on paper and much easier to change as we work it out some more.

We must be careful about being too sequential in our thinking when planning. We need to think holistically as we work out to successfully deliver our new project. That is, work from a high level down.

Too many PM’s try to start planning at the perceived start of the project and then attempt to think of everything that needs to be done in sequence.

Don’t do this.

Your projects will suddenly take you months (or even years) longer than expected, you will get bogged down in detail and will likely miss something that needs to be done. And most importantly – never seem to get started. (And likely have a plan that will be off track before you barely get into it).

Work from a broad overall picture then tease out the detail.

Anyone who has done any painting knows this – try painting a portrait from the top of the canvas to the bottom every little detail as you go – and see how good the painting is in the end! (It can be done – but you need to be an outstanding technician, very experienced and very familiar with your subject.)

By working with a broader overall context first and refining things as you plan, you have a far greater advantage over the sequence driven planner – you can stop at whatever level of granularity is appropriate for now – and be confident you have not left out anything even if you are not sure about the detail yet.

To do this, start with the end in mind. In our project world, this means starting with a clear definition of what we want at the end.

The PRINCE2 methodology has a nice way of doing this – with a “Project Product Description” – a brief description of the overall “product” or set of products that you are going to deliver. (PRINCE2 uses the term “Product” instead of “Deliverables” – I will use the terms interchangeably – but understand they mean the same thing – something you can point at in the end).

In reality, this overall vision can be in the form of a concept model of any type – document, drawings, computer presentation/mockups, physical models. The clearer, the better. As long as the key people involved in your project agree what it is.

Next – agree on the definition of “done”. That is, when is the product considered complete?

So

Step 1 – Have a clear definition of what it is your project will deliver in the end.

Step 2 – Define “done” for each deliverable.

This is the starting point to having a plan that is focused on what the project owner wants while at the same time stopping us from over thinking everything in a sequential manner when we do our planning.

If you are in the software development world and you are using agile software planning – the principle still applies. You start with story “epics” that denote the essential pieces of functionality that make up your new overall product.

Planning for a Product-Driven Project

One of the best ways to achieve the happy medium in terms of detail in your plan is to start with this end-project vision and break it down into the various components or “sub-products” that must be delivered to get us there.

You can (if you want) draw up a dependency diagram of the components of your products; however, a simple indented list does just as well.

Don’t be tempted to get into activities and estimates of time and resource allocations just yet. That comes later. Just the thinking that goes into what we need to deliver overall as interim deliverables towards that overall end product is what is important.

Here are a couple of examples of the type of thing I’m talking about as a simple indented list:

  • Big Expensive Software Product
    • Functional Requirements Document
    • Tender Request Document
    • Budget Plan
    • Business Case
    • Evaluation Criteria
    • Evaluation Team
    • Legal Team
  • New Warehouse
    • Plans
    • Council Submission
    • Budget Plan
    • Road Access Plan
    • etc

Remember everything in the hierarchy is something you can point at later. Products (or deliverables) are things you can see and touch. We normally use nouns to describe them.

By the way, I’m not trying to advocate PRINCE2 in particular (although it has a lot of advantages for the more formal project environment) – however, this is one very nice aspect of that methodology that is useful for many projects. 

Often people say – “but, my project is a doing thing, like – move the office to a new location, purchase a new software package, migrate the data center”.

Yes – these are actions. But these are actually the outcomes we want to achieve – “I want to move my data centre into the cloud” – is an outcome or objective of the project owner.

Certainly finding the appropriate thing / noun from this as your first instruction can require you to flip your thinking – but work with it. It’ll be worth it. The deliverable, in the end, are still things – “outsourced data centre”, “software x”, “new office”.

So start with a clear definition of what it is you want to deliver IN THE END and work holistically – use a “broad brush” approach sketching the overall picture and then work out the lower level components – all things you can see and touch. Have a definition of “done” for each.

Work on detail for the first things you need to do for now.

Such a simple process. It will deliver the results you want.

Happy projects.

Mark