The Plan for the Plan

We all know what a plan looks like.  Objectives & scope locked down, funding secured, work breakdown structure defined, schedule in place, governance established, reporting kicked off, project team engaged – easy….. Right?

How did you get to that point, where you’ve successfully managed to get to that point?

How did you manage the expectations of stakeholders, customers & team members, whilst you were figuring out what you need to get done to achieve the desired business outcome?

How did you take the napkin page of desires and develop it into a detailed scope, which reflects the stakeholder’s objectives AND also made it achievable?

All the while, managing the expectations of your stakeholders, where they believe you should be off and running, completing deliverables, and getting closer to final delivery.   In many situations, the weeks, and sometimes couple of months of planning required, is seen as a luxury that “we can’t afford”.  How many times have you heard, “just get on with it and delivery me the benefits”?

One way of managing this often hectic time and the desire to demonstrate progress, I call “The Plan for The Plan or P4P” (at this point I must recognise the Managing Director of TBH who use this a point for any project TBH Was engaged on. Since that time I have claimed it as mine).  As with many of my concepts, it is a simple, and if executed well, it can be very effective.

Sit down and think about your program, talk to your stakeholders and key people.  What do you need to get done in the coming 3-4 weeks, and what can you realistically achieve in that timeframe? Create a list of actions/deliverables that will help you get your program organised; frame them all around things that you can report to your stakeholders and project team.  Things like:

• Objectives defined and agreed with stakeholders
• Milestones identified and targets timings for each
• Governance committee identified, and meeting established
• Work breakdown structure
• Detailed Delivery Project Schedule
• Roles and responsibilities drafted
• Detailed schedule developed
• Risks identified and classified
• Architecture drafted, etc….

Develop the logic and resourcing for each item which will give you a target date.  Think about how long it will take to arrange, do you need to hold some workshops, meetings?  When will people be available?  For your schedule, you will need a few sessions with your team, reviewing and re-working the dependencies.  Can you get that done in 2 weeks, or 3 weeks?  It will depend on how busy the team are, and what time they can dedicate?

 

Refine your schedule into a list of 6-8 clear items that give the stakeholders clear understanding on what you are working on and when they will get the completed project schedule.  This can be presented to your project team as the focus for the first few weeks of the project.  This can presented to your stakeholders as a progress or status report.  Failure to achieve some of these key items will indicate your project has some risks that need to be addressed early and help the overall delivery of the project.

This schedule is “The plan for the plan”.  Once you complete this mini-plan, you will have an understanding of your project objectives, deliverables, schedule and risks.  You will have a detailed plan you can execute and track progress against.

“The plan for the plan” gives you something you can present to the wider organisation that shows your targets for the coming weeks, you can demonstrate progress and control while you are getting the program organised.

Just make sure that during this process you ensure that the team is focusing on the bigger picture and planning the whole project. You don’t want to get to the end of the P4P and not have a clear delivery methodology (Including Risks, Assumption etc.) and project plan to baseline your project to manage the rest of the project performance by.

 

Think about it!

 

 

 

Good luck with your projects….

Project Recovery 101

In recent times, IT project success has become something to be celebrated and cherished as many enterprise projects have languished due to lack of direction, funds or objective. Gartner’s research had reported that at least 40 to 55 percentage of projects initiated in the United States have not completed their expected lifecycles. This statistics has been compiled from the days when projects were initiated to resolve Year 2000 computing issues to more recent web based portal and virtual world projects.

For an IT Project Manager, setting up a project for total success becomes his first priority whether that involves securing sufficient reserve funds or obtaining absolute commitments from the business sponsors. Many a times a Project Manager could be called upon to rescue a project from bleeding valuable enterprise funds and personnel resource time.  How does a Project Manager effectively lead an effort that takes a project perceived to be in a sick status to a successful one?

A PM in charge of recovering a project soon realizes that not much project trail can be found about the project that needs rescue. After all, most project documentation revolves around success scenarios and plans that envision the project to be successful. However, it will be wise to pay attention to a few known elements that halts such projects.

Business case priority:  Avoid implementing project scope deliverables that have the least priority for the business. While it is true that most projects take off after a formal signoff of the business case definition, priority analysis of these business cases need to be evaluated over the course of the project when as part of the rescue. A single project could comprise of many business cases or different elements of a business case. A PM should be able to identify those business cases that had lost priority from a business partner’s perspective. This will save valuable project execution time as well as improves the project’s acceptance probability. The rescue effort will begin by reassessment of the business priority of the business case. By enlisting the support of business and technical stakeholders, the PM can facilitate an executive decision to remove such business cases from scope through proper change management process.

Project Methodology:  Decide on a Project Management methodology that is accepted wholeheartedly by all project stakeholders. It is a common belief if a recognized industry standard project methodology is adopted, enterprise projects will run like a well-oiled machine. However, in practice, special attention should be given in adopting the methodology whether that is Agile, Waterfall or Hybrid. As an example, while Financial Institutions might want to roll out project releases at a brisk pace, they still will want to adhere to time consuming mandatory IT controls. While it may not be advisable to change project methodology while the project is in progress, a realistic rescue effort will demand a re-examination of the adopted methodology. The best solution will be to downgrade the ill effects of the existing methodology and introduce new elements that can facilitate the smooth execution of the project. However, the project stakeholders should be completely subscribed to the adopted methodology through brown bag sessions, change meetings and lessons learned sessions.  The PM, through stakeholder consensus can schedule a User Acceptance phase in parallel to a degree with a System Testing phase on components that are relatively stable. Also, some cumbersome stakeholder signoff requirements can be trimmed from the acceptance criteria after documenting such a decision.

Technology Assessment: Select a technology architecture that fits the architectural direction and operations environment of your enterprise. During a project rescue phase, it might not be feasible to make a serious departure from an earlier project decision to adopt a specific technology.  However, the rescue PM should document the drawbacks of such a technology in the specific project with the help of an Architecture Review Team. Once that has been achieved, a review of possible amendments to technological components can be started with timelines aligned with the project construction phase. For example, a project technology team might have selected vendor product for middleware integration while an in-house tool provides a much faster solution. While the vendor product may offer a long term value, the PM will have to make a case for the in-house solution by projecting the advantage of completing the construction phase as well as avoiding costly integration test nightmares.

Team Effectiveness: Make hard decisions in retaining or rolling off staff from the project team. A rescue PM would have the least influence in selecting the ideal project team due to many possible team composition iterations that may have occurred during the course of the project. However, a strategy for improving team effectiveness should be devised to facilitate the smooth execution of the project. This can be a two-step approach where the rescue PM starts evaluating the prior performance of the project team members and makes off-boarding and retaining decisions. It should then be followed by a series of team effectiveness improvement sessions that will comprise of expectations settings on project communication, team member accountability and measurement of performance.  While these formal strategies will cement the notion of a structured project team operation, special attention should be paid to organize team building and team feedback sessions. As an example, while face to face meetings provide a good way of communicating project progress, it has been found that a series of remote meetings with the help of online team collaboration and voice conference tools as a substitute can work wonders in increasing project meeting participation.

Now, the big question on the horizon is, How do we measure the success of the above mentioned efforts towards the rescue the projects? If the project completes with expected variances in scope, schedule, cost and quality, it definitely can be termed a success. However, measurement of success for rescue projects is not that simple.  When the PM takes over a sick project, many of the project metrics would have exceeded the variances expected by the stakeholders. A PM should set expectations on the project success measurement with stakeholders by

1. Obtaining a project success criteria with variances on scope, schedule, cost signed off
2. Setting up periodic project quality checks by a stakeholder committee
3. Escalating project environment issues  and its impact on deliverables
4. Requesting allocation of reserve funds and resources based on stakeholder priority

While a PM can follow strategies, best practices and methodologies for rescuing an IT project to success, a PM’s emotional intelligence and its adoption towards overcoming project challenges will play an important role.  A PM’s experience in executing multiple complex projects over a substantial period of time will also be an asset for project recovery efforts.  As more and more IT projects get funded to be executed in a compressed timeline in the enterprise landscape, project recovery will start playing a much more important role than standard project execution making such a discipline very relevant in our times.

Managing Project Risks in Four Simple Steps

What are project risks, and why do we manage them? In simple terms, a project risk is one answer to the question, “What could go wrong?” If you can anticipate potential problems that would impact your project’s quality, budget or schedule, taking steps to prevent them makes a lot of sense. Additionally, having a backup plan in place amplifies your ability to recover should one of those risks become real. Thus, risk planning greatly increases your overall potential to lead a successful project.

“No battle plan survives contact with the enemy.” – General Colin Powell

I say it a little less dramatically: “If you don’t have a Plan B, you don’t have a plan.” (Yes, you may quote me…) Let’s walk through the four easy steps to building a risk management plan. These steps are based on straightforward questions, which in my experience add a level of clarity that is sometimes missing.

1. List potential risks. To build this list, simply ask “What could go wrong?” or “What if…?” As you brainstorm the list with your team, assign a probability for each. You don’t need to get fancy or over-think it. Just give it your gut feel on the first pass. You can always adjust it later. Make it easy. Is it likely, or unlikely? Is the chance of this occurring high, medium, low? That is plenty of detail for this approach.

 

2. Establish a mitigation plan for each risk. For each item on your list, ask “How do you prevent that from happening or at least lessen its likelihood?” The answer to this question is your risk mitigation plan for that event. Reducing the likelihood of a detrimental event occurring is the ideal risk management strategy. Prevention is better than remedy every time.

 

3. Develop a Plan B. Ask yourself, “If that event does occur, what is Plan B?” For the high probability risks, you will want to have a Plan C too. Document the backup plan! Now take a quick look at the big picture. How likely is it that Plans A, B (and C) would all fail? That should be very unlikely, which means you have reduced the risk of failure!

4. Assign a risk monitor for each item. “Who would be the first to know?” That is your responsible person. That person is to monitor and report to the project manager immediately should a risk occur (or even be anticipated). If something goes awry, the risk monitor is your first line of defense. This does not mean everyone else can abdicate responsibility for monitoring risks; the whole team is responsible, especially if something happens that is (dare we say) unforeseen.

 

So how do you document steps 1 through 4? There are numerous templates and tools available, so search around and choose one that seems a good fit for you and your organization. At a minimum, the risk log should include the following categories:

Description of risk

Probability

Mitigation plan

Plan B (the backup plan)

Assigned risk monitor

Additional fields that may be beneficial:

Risk identifier (just a sequential numbering system will work. I use R-1, R-2, R-3, etc.)

Current status (active or inactive)

I’d like to express one more thought concerning risks versus issues. In practice, risks and issues can get muddled in the minds of team members. This is especially true in organizations with less savvy project team members. For this reason, I include a simple distinction within the narrative portion of my project plans. Simply defined, a risk has not yet occurred, but an issue is happening right now. Then I elaborate a bit further just to confuse them a little (I’m kidding): So, if a risk comes to pass, it can be considered an issue, but an issue does not have to start as a risk–it might be unforeseen.

 

So there you have it, four simple steps and the elements of a log to document your risks. Use these steps as outlined to reap the benefits of this oft-neglected area of project management. Here is what you get for investing the time to develop a predetermined set of risk management actions:

 

increased likelihood of successful project completion

saved time that would otherwise be used figuring out what to do when something goes wrong

documented plans and strategies for future reference

increased confidence in the overall project plan

increased control of the project

And as if all these benefits were not enough, you will surely look like a hero if something does go wrong and you have the backup plan all lined up and ready to deploy.

When Estimates Go Wrong!!!!!

“What’s that ticking sound coming from the engine of the car? Must be a loose valve. I’ll take the car to the mechanic for a valve adjustment…”

At the garage, they look up the flat-rate time estimate for a valve adjustment. It’s easier to estimate when you’ve measured the actual time from lots of competent people doing very similar work. They multiply that time estimate by their labor rates, add in some extra for gaskets, shop supplies and such, and give me a cost estimate. “It should be ready by 5:00.”

I go on my way, knowing I can pick up my car in the evening and how much it’s going to cost me. All is right with the world. But in the late morning, I get a call from the mechanic. “Your car doesn’t need a simple adjustment. The pushrod is bent. The reason it got bent is that the threads holding the rocker arm assembly are stripped out of the cylinder head. We’re going to need to keep your car another day, and the cost will be about triple the original estimate.”

What do I do with this information? I could berate the mechanic for giving me a bad estimate. I could insist that he only charge the originally estimated amount. I could tell him to work through the night so that I can pick up my car first thing in the morning.

I suspect that you don’t do any of those things. I don’t, partly because I don’t think it will get me what I want. Instead, it’s likely to damage my relationship with the mechanic, and get me less of what I want.

Custom software development is notoriously difficult to estimate. We start with vague ideas of what we want, expecting to fill in the details later. We’re usually doing something a little different than what we’ve done before, or completely different. If it weren’t different, we wouldn’t be doing it at all. Software development is orders of magnitude more complex than fixing a mechanical system. It’s fractal, whereby whenever we go into more detail, we also discover more complexities. It’s a very creative endeavour, requiring intelligent imagination.

We compound the difficulties by not keeping records that allow us to compare this work with previous work. We change the makeup of teams, so that even when we can compare the work, we can’t compare the workers. We add bureaucracy and technical constraints that may not be obvious when making the estimates. We change the circumstances after the estimates are made. We often expect other work to be done in the same time as the estimated work, without accounting for the loss of time and efficiency due to multi-tasking.

In spite of all these difficulties, I’ve observed managers berate developers for bad estimates, insist that they finish the work on the previously estimated date, and demand they work overtime to do so at their own cost. This article is not, however, about all the costly damage done by such reactions. Instead, let’s look at how we can act more productively.

When estimates and actuals don’t match, trust the actuals. Should you adjust the estimates to match? If you do this, then you can adjust the plan accordingly. How early can you test the correlation between the estimates in your plan and the actual rate of progress? When work is performed in large blocks and integrated at the end, it’s far too late for effective re-planning when the difference is noticed. How can you validate your plan earlier?

Working in small increments and continuously integrating can help, but you also need to know that those small increments are actually done. Using estimates of “the database layer is 90% done” won’t help, as you’re back to depending on unverifiable estimates. Rather than creating small increments based on the building blocks of your project, try using small increments of functionality. These functional slices will touch numerous building blocks, but can be tested unambiguously as to whether or not they work as desired.

After re-planning based on the reality you observe, you can attend to fitting that plan into your constraints. If progress is too slow to fit everything you want into your budgeted time or cost, consider trimming the scope of the work. This can be done by eliminating features, or by slimming features down into easier–though less capable–versions. You may have to make some difficult decisions about priority.

Observe where your delays and bottlenecks are. What makes the actual speed as slow as it is? If it seems that things “should be faster”, then it’s possible they would be–except for an accumulation of difficulties that impede progress. Perhaps there are some quick wins in out-dated procedures that can be eliminated and speed up progress. Perhaps the internal quality of the code has been ignored to the point that everything is hard to change. It will take time to improve that quality, but it will eventually pay off in faster development speeds.

Make adjusting estimates easy. Estimate in artificial units, and roughly correlate the artificial units to the ones you need to examine. People use story count, story points, t-shirt sizes, animals and other analog for estimation sizes. Try to be consistent, but be aware that estimation will vary over time. An advantage of artificial units is that you don’t have to go back and re-estimate when the apparent speed changes. If you were accomplishing 38 stories per month, and now you’re accomplishing 46, you don’t have to worry so much where that 8-story-per-month improvement originated. Merely project using the newer figure, and see what that does to your plan.

Don’t expect estimates to be precise. If you need them to be precise, you’re trying to plan too close to the edge of failure. Don’t rely on optimistic numbers. Also think about what a downturn would mean. Don’t validate your estimates with reality only once. Continue to re-check throughout your project. Work in priority order so that you can re-plan frequently to the end, but still deliver the highest priority functionality. And if you cannot prune the scope to fit and still achieve the project’s value, then you’re likely to be working on the wrong project.

As Tom DeMarco said, “Strict control is something that matters a lot on relatively useless projects and much less on useful projects.” [“Software Engineering: An Idea Whose Time Has Come and Gone?”, July/August 2009 IEEE Software, pp 96, 95] Projects with a high return on investment can survive a few inaccuracies in estimation. Projects that need precise estimates likely won’t return their investment.

Recovery? on the back of a coaster? Never going to work.

I want to share my experience of the PPM Community and how i have seen the teams on how they take on the re-baselining and recovery process with in flight projects.

Usually it is started at a point that the delivery project team is starting to miss major deliverables  and the client just wants to be able to get a date that they can commit to all their internal parties with out having to go back again. This is shortly followed by a deadline of 2 weeks to re-plan the whole project , dependencies, resource plan and activities and come back to the them with the date they could meet meet.

Because this decision is usually made at a steering committee and it takes 2 days to filter down to the PM’s that this will need to be executed by.  Once the PM hear the pressure is off they are usually mid flight in a process and puts this opportunity to a low priority on top of all the other requests made on them by all of there stakeholders.

So now a week later the PM is tapped on the shoulder and by the Program Manager asking how the re-planning is going usually meet with a very blank look. Followed by a conversation about what is a higher priority getting the activity that he is currently working on or this re-planning exercise?

Then in the new week the PM starts to get his team together and promptly realises that it cant be done in their isolated stream. The PM proceeds to get all parties in the room to ensure that this plan contains all the know work they need to do to get to a point  the client will be happy with.

The planning is complete in a day on a white board and the all the problem that the PM has been facing over the duration of the project so far are not factored in and a miracle date is produced and promptly communicated to the client……….. very shortly followed by some time being lost in the communication between the executives and the client.

Why do PM’s who understand the project in detail

1. Not do proper planning using a CPM tool?
2. If under pressure request for specialist support to ensure a plan contains risk, assumptions and required commitment?
3. Never add any contingency in the plan based on what has happened so far?
4. Never ensure that the contract requirements a retested against the new plan?
5. Never contain the outstanding work?
6. always have the highest technical risk?

I know all of these points above will not return a palatable result but this gives you and your client a full understanding of all of the risk that they are asking you to take and what impact that it may have on their business.

Top 10 Questions for EVM Readiness

I completed an assessment on earned value management readiness based on 40 critical success factors found in successful earned value management implementations. The project managers in the assessment provided feedback on the assessment statements and their usefulness in determining earned value readiness in their own organizations. The assessment statements were ranked according to their usefulness in determining EVM readiness.

The top 10 in order of priority are:

1. The PM staff demonstrates the ability to develop project schedules and track against a baselined schedule as evidenced by project schedule baseline and actual variances, milestone counts and late task counts.

This assessment statement isn’t a surprise, as having a strong competency on schedule development and schedule management is critical for an EVM implementation. A poorly defined project schedule will still be a poorly defined schedule even if you try to apply earned value metrics against it. By focusing on the core competency of schedule development and scheduling tracking, project managers are establishing a critical success factor for EVM.

2. The management supports EVM and provides a top-down direction on its use and application to project management as evidenced in management communications and project portfolio reviews.

In assessing and talking about organization change management and project sponsorship, I often hear the overused words “top-down management support”. I’m sure you’ve heard it so many times in your project management classes that you may have glazed over this assessment statement. We’ve all heard it and acknowledge it yet can reluctantly admit to have vainly tried to implement project best practices without it. With successful EVM implementations, you need the organization’s support and its inclusion in portfolio reviews and management communications. If the organization isn’t behind your effort, its impact will be significantly minimized.

3. Resources (personnel, tools, funding) are committed to implement the EVM initiative as evidenced in the department budget.

If EVM is going to be successful in an organization, it cannot be left as a bottom-up effort from the resource pool of project managers. It needs to be a funded effort with coaches, scheduling tools and training to make EVM successful. One solution is to have the enterprise project management office fund EVM training and coaching at the corporate level.

4. The organization’s project management methodology uses objective status metrics in project status reporting with such metrics as milestone counts, schedule variances, cost variances and deliverable tracking.

Earned value management is a quantitative method to report project progress. If the organization is not already incorporating milestone counts, deliverable reporting or some form of objective reporting, EVM might be too advanced of a concept. Start out with simple task or milestone tracking and introduce SPI as organizations understand the value in objective performance reporting.

5. The staff has the necessary skills and resources to implement EVM as evidenced by training history, staff confidence or defined roles and responsibilities documents.

Similar to assessment statement No. 3, the skills and resources need to be in place to support an EVM implementation. If the organization doesn’t have the skills in-house, hiring external consultants to implement the methodology, provide coaching and knowledge transfer will help develop the skills within the organization.

6. The project has well defined scope as evidenced by a scope document, requirements document (or specification) and a work breakdown structure.

If the project isn’t well defined in a project schedule with a time-phased budget, it becomes impossible to track the project with EVM. A well-defined WBS, scope document or requirements specification needs to be available to support EVM. If the organization doesn’t have one of these fundamental project management artifacts, the organization should focus on creating them before jumping to an EVM approach.

7. The project organization understands earned value management concepts as evidenced by PMP certification, existence of an EVM process guide or use of EVM terminology.

Before EVM can be implemented on a project, the project organization needs to understand the concepts behind EVM. Otherwise it just becomes a metric that “my boss says I have to include” versus a metric that identifies project problems early.

8. The PM staff has a high level of project management experience and maturity as evidenced by process quality assurance audits and skill assessments.

Project management maturity is another critical success factor. If the concept of project management is a fledging activity that is non-value add, then an earned value implementation won’t be successful. Organizations that use EVM have a mature project management staff that understands the value of project management as a role and discipline within the organization.

9. The project managers in the organization are PMP certified as evidenced by a count of all PMPs in the organization.

In today’s market, obtaining certifications has become somewhat of a commodity. In a weekend, I can take a PMP preparation class and have enough practice to take the exam. Despite the commodity debate, having a PMP certification ensures you have common language with your PMP peers and all should have an understanding of earned value management. EVM is covered on the PMP exam and is a good indicator if the project staff has a baseline understanding of the concept.

10. A designated PM is assigned to manage each project as evidenced in a project roles and responsibilities matrix or project charter.

This assessment statement is another indicator of project management maturity. If the role of a project manager isn’t defined for the project, the notion of earned value management becomes an obscure and theoretical concept. The project team will have bigger project challenges that EVM can’t solve.

In my assessment, these were the top 10 of 40 assessment statements based on the project management community responses. Future extensions of the research involve consolidating the 40 assessment questions into a smaller subset for faster assessments. Do you agree or disagree with the top 10 assessment statements? What other assessment questions would you ask prior to implementing an EVM solution? Please comment in the section below.

The top ten principles for any Change Management

The top ten principles for any Change Management programs.
2/10 – Start at the top. Because change is inherently unsettling for people at…

Ten Actions to develop success on a project

1 – Follow a process.

This depends on the company that you work for as they may already have a project management methodology in place, so you will have to follow that, but don’t let it stop you suggesting new ideas. Read and keep up to date on good project management practices, you may be told to do this by your work, but you should be doing this off your own back. Most companies with a current methodology will have a diagram of their general processes, print it off and keep it close to hand, it can help you to keep on track.

2 – Ask for a Mentor.

Two heads are better than one, especially if the other has more experience and knowledge than you. This kind of help can prove to be invaluable to you and the company, you can always learn more. Your company may suggest a mentor or you may have to go searching for one, if you can, try and find someone with a good attitude as this will rub off on you.

3 – Surround yourself with tools.

Find as many things as possible that can help make your job easier, every little thing can be combined to be a great help. There is software available to help you; plan your project, for task management, create great mind maps and create logs for issues and risks. If you aren’t to hot with computers then you should think about learning about this software, but for the moment, Microsoft Excel will help you with lots of things, its very versatile.

4 – Templates to Save You Time.

You have probably been doing this for some time so you may already have a set of templates that you have created and changed to fits your needs. But if you don’t have your own, there are many available on the internet, some are free and some you may have to pay for. These templates are great for saving you time and you should be able to fit them into most companies.

5 – You need to Plan.

Creating your own plan can save you so much time and time cost money in business. It helps you to structure your work life and allows you to deliver what is expected of you on time and properly. Making a good, solid plan is very important, if you get it right then the project will run smoothly and the product will be produced on time and within budget. It will also help you to show your boss(es) what you will be doing and it can bring up potential hazards that may not have been noticed without the plan.

6 – Communicate with the stakeholders and agree on the plan.

When you have written up your plan for the project, you need to show the stakeholders and they need to fully understand what will be going on in the project. They need to know what is going to be the end product, how the project will pan out, who will be working on which parts, how long it is expected to take and all the costs involved. The stakeholders are there to help make decisions so once everyone understands the project, if any changes need to be made, before the project has begun is the best time to make them.

7 – The project needs to be managed and tracked.

Once you have agreed upon the project plan with the stakeholders, the project can commence, so you need to keep on top of it and make sure the work is actually being done. This means you need to be involved in managing your team correctly and keeping track of all tasks as they go. It is a good idea to have regular meetings with employees or team leaders to make sure that everyone is still on track and to help put right any problems that have arisen. If there have been targets set and employees know there will be a meeting about it imminently, it will push them to get the job done which will help the project to stay on track. This will also help the project team to see the bigger picture as all their individual components come together.

8 – Manage ALL Issues and Risks Correctly.

One of your top priorities as a project manager is to keep on top of all issues and risks within the project. If an issue arises, it’s much better to tackle it early rather than leave it till later, in which time the issue could get worse and knock the project off track. If you successfully manage an issue or risk, both your team and customers will have more confidence in you.

9 – Progress Reports should be created regularly.

Everyone involved in the project including the project team, stakeholders and customers should be kept up to date on how the project is coming along. No one likes being left in the dark about things, especially customers as we live in the digital age where we expect things instantly. You don’t have much spare time and neither do most other people, so these reports need to be straight to the point, no need to write an essay when a simple – ‘Project is going well and is on target to be completed on time’, that’s all you really need. This also reinforces the fact that you know what is going on within the project and allows you to answer any questions thrown your way.

10 – Deliver, Deliver, Deliver…..

A completed project is what you are always aiming for and is what your customers expect from you. Delivering that product is paramount to keeping a good reputation within the company and to other potential customers, reputation is everything! Parts of the project should have set due dates so that the project team has something to aim for, apart from the overall completion date, and also allows you to know if you are on track or not.