Skip to main content

Tag: PRINCE2

5 Effective Project Management Methodologies and How to Apply Them

Written by David Baker on . Posted in Articles. 4 Comments on 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

Written by David Baker on . Posted in Articles. 71 Comments on 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?

Written by Phil Jacklin on . Posted in Articles. 9 Comments on 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

Written by Mark Broadbent on . Posted in Articles. 4 Comments on 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

From the Archives: 4 Key Project Monitoring Steps to Help You Succeed

Written by Lori Benson on . Posted in Articles. 8 Comments on From the Archives: 4 Key Project Monitoring Steps to Help You Succeed

Trust, but verify.

Whether you believe this sound piece of advice first came from former President Ronald Reagan or derives from an old

Russian proverb, the fact is that for decades these three words have become a mantra for both corporations and government agencies that want to affect meaningful change in their organizations and need to know that it is really and truly taking place.

Given the pace of change, and the necessary steps to make meaningful, long-term change happen—especially in a large organization—verification typically needs to take place frequently,  throughout the lifecycle of any project. In other words, organizations could just as easily embrace the motto: “Trust, but monitor.”

Project monitoring is a necessary component of all project management plans. Without project monitoring, organizations may fail to understand why projects go awry, and even successful projects may have insufficient impact. The project coordinator (or project leader) and their supervisor should plan from the start on project monitoring being an important, integrated, and continuous part of the project management cycle.

Within the project monitoring feedback loop, the information and results from the ongoing project should not only be reported back up the chain (to supervisors, managers, the top executives and potentially the board or other invested parties) on a regular basis, but also back down to the project participants.  When necessary, information should also go out to the frontline employees as well. It is the role of the project coordinator and the project coordinator’s supervisor to monitor project information and use this two-way flow of project monitoring to ensure the implementation of projects as efficiently and effectively as possible.

By following these four steps, project leaders can better ensure the successful flow of information, results, feedback and advice throughout the project monitoring process:

1.    Begin with a plan for project monitoring.

It may sound simplistic, but many an important project was started in a hurry and bluster, with the plans for any kind of project monitoring pushed to the side (to an undecided ‘later date’) in the interests of quickly moving forward. This kind of ‘act first, think later’ strategy has led to myriad of planning challenges, and can ultimately lead to ineffectual results or a lack of learning or benefit from the project in the long-term.

Project leaders must begin with at least a basic plan for how, when, and what about the project they plan to monitor. Base the plan on realistic targets.  If the project leader cannot commit to monitoring and reporting results back on a bi-weekly basis, plan from the start to report back findings on a monthly basis. The project leader should make sure to consider the resources they will need to monitor adequately and report back information about the progress of the project.  Resources may include technological resources and personnel (on the project team or potentially outside of it)— ensuring those resources can be available to them as needed for the purpose of project monitoring. Monitoring a project is often not a linear endeavor. Oftentimes, the project will require more frequent monitoring, results review, and feedback early on to ensure that the progress is moving along, that all the participants know their roles, and that the project is generally meeting its objectives in general.

Related Article: Project Check-Ups to Keep Your Projects Healthy

Increasingly there is a greater emphasis on demonstrating performance rather than simply producing outputs, which could change the way monitoring and reporting on projects is handled. But, it is important to remember that monitoring is the continuous process of assessing the status of the project and how it is developing in relation to the approved work plan and budget. Successful project monitoring plans, while they may seem superfluous, actually help to improve performance and achieve results.

2.  Report to management.

Project monitoring may be carried out informally through weekly meetings, or formally through written reports. But what is most important is that there is a regularly scheduled time each week, month, or quarter when results or progress about on-going projects is expected.

Regular monitoring enables the project leader to identify actual or potential problems as early as possible so that they can make timely adjustments to project plans and move forward. In addition to tracking the outputs and measures of their project team’s contributions and periodic results, project leaders should be mindful of spending and milestone tracking. Particularly in today’s budget-conscious environment, the C-suite must be cognizant of the bottom line. If a project looks like it may go over budget, or if earlier results are indicating a need for greater spending or extending the project, top managers must be alerted.

imilarly, it is important for the top brass to be made aware of how the project is faring in meeting its prime objectives, and the milestones that lead up to these goals. When reporting to organizational leadership, project leaders should focus on results that indicate whether a strategy is relevant and efficient or not.

3.  Recommend actions to improve on the project.

This is the step that tends to come to mind first when people think of monitoring a project. It’s important to remember that recommendations without the previous foundation of solid planning and feedback from management and the project team itself, based on budgeting and meaningful goal-setting, will be relatively pointless.

Project leaders should think in terms of priorities—reference the project plan or the mission statement to keep focus on the ultimate goals of the project. What are the key process improvements that will offer the greatest bang for the buck in terms of keeping that project running smoothly, efficiently, and on-time? Recommendations could include corrective actions, preventative actions, or changes in the plan or the project execution.

When making recommendations, guidance should be as specific as possible: direct the project team member deemed responsible to make a specific action by a specific date, and make certain they are slated to report back to the project leader on the results of their action. Keep in mind the team’s own health and feedback: offer constructive criticism and praise when it makes sense to strengthen the goals of the project and the team individuals’ work too.

4.   Confirm that actions are being followed.

Trust that your team, with proper guidance and oversight, will make the appropriate corrections as needed. But again, the project leader must verify that recommendations are being followed and the project as a whole is staying on track.

Project leaders should consider the use of automated tools and technologies in order to track team members’ performance and response; share documents, feedback, on-going recommendations and suggestions, and forecasts; and communicate among team members about meetings, and updates in the project management plan. At the most basic level, the project leader must track the differences between what was planned, and what is actually happening to ensure that project objectives are being met, the accuracy of initial cost estimates and planned resource requirements, and whether the expected outputs are being created.

**This article originally appeared on our site on October 15, 2015

http://www.businessnewsdaily.com/9228-pokemon-go-business-strategy.html