A to Z of Project Management

Think Oak!, Mark Conway, Project Management

Most business leaders are acutely aware of the dynamic nature of the business and economic environment and more so today than ever before. Every organisation big or small has to take into account priority, time, resource allocation, scope and budget of each project within their organisation. It is only if these factors are well managed with consistent project management processes, that business will  thrive and get good results. So, to effectively meet the dynamic nature of projects, great project management is a must in business. Delivering a quality service or product is seen as the mandatory obligation for business survival.

In this A to Z of Project Management, I’d like to focus on some of the more critical areas of focus for Project Managers and those working on complex projects.

A – Acceptance Criteria

Acceptance criteria are the specific set of conditions that must be met before a project has been considered completed and the project deliverables can be accepted by the customer, be they internal or external. Normally the acceptance criteria should be outlined in specific detail and signed-off before work on the project has commenced to ensure that all parties are in agreement.

Acceptance criteria are typically used on projects where the customer is paying for specific deliverables or for the completion phases in a project.

You should ensure that the acceptance criteria that are developed, are appropriate to the deliverables, are binary (either acceptable or not acceptable), are measurable, and tied to payments (whenever appropriate). Customers are refuse the sign-off on the deliverables for two legitimate reasons; either the project results have not met their needs, or they themselves were not clear about their needs. By working towards a clearly defined set of acceptance criteria before you start working on your deliverables, you will be protecting yourself, your project team, and your organisation.

B – Business Case / Benefits Realisation

Before the Project: The purpose of the business case is to outline the rationale for undertaking a project, and to define the parameters and management factors involved in the project itself such as time, quality, cost, resources, materials, benefits and timelines. It provides the project manager with a tool to guide the design, management and evaluation of the project.

The business case serves three purposes: it provides the project manager the opportunity to think through the project in a systematic, step-by-step manner; explains why the project should be undertaken; and provides a framework for completion of the project on time and on budget.

During the project: The business case should be updated to reflect actual costs incurred and any changes to forecast costs and benefits. This information can be used by the Project Board to assess whether the project remains viable and to take decisions accordingly.

At project closure: The updated business case should be handed over to whoever is going to take long-term responsibility for delivering the benefits.

Benefits realisation stage: The business case will be used as the baseline against which to measure achievement of the actual benefits and to inform any resulting decision-making. A Benefits Realisation Plan produced during the end of the project should be used to establish what each benefit should be, the units it should be measured in, the optimum timing for measurement, the method of measurement and responsibilities for realisation and measurement.

C – Critical Path Activities and Analysis

Critical path activities are the project tasks that must start and finish on time to ensure that the project ends on schedule. A delay in any critical path activity will delay completion of the project, unless the project plan can be adjusted so that successor tasks finish more quickly than planned.

D – Delivery Success

Delivery success has got to be the number one goal for a Project Manager. Below are 3 key areas that I believe are the keys to delivery success (apart from you being a fantastic project manager, of course!)

1. Comprehensive Planning

Comprehensive planning sets up a project for success from the start. All stakeholders should be on board during the planning process and always know in which direction the project is going to go. Planning can help the team to meet deadlines and stay organised. Good planning not only keeps the project team focused and on track, but also keeps stakeholders aware of project progress.

This first step in the project process allows for a reliable and realistic time-scale to be created. Assuring accurate time for cost estimates to be produced and for clear documentation of milestones and deliverables will make things much easier as the project progresses. A proficient plan details all resource requirements and doubles as a warning system. If task slippage is at risk, then a warning system will provide clear visibility of what to expect.

Use the best planning tools possible to help you and utilise lessons learned from previous projects to help you avoid those common pitfalls in planning

2. The Right People

Without the right team in place, any strategy and plan has the potential of completely falling apart. Because of this, the core project team, expert resources, suppliers and key stakeholders should be part of the team from the outset. All of those involved must have commitment to the group, share similar visions for the projects and strive for overall success.

Project managers can face serious trouble if inadequacy is present within the team. Inept leadership or an out-of-sync team can send a project towards failure. It is important to assign the right people to each aspect of the project and make sure that they are working well together. Additionally, the entire team should be completely informed and involved in order to have the most successful outcome, which means that communication has to be a key priority.

3. Communication

Keeping open communication within the team is absolutely essential. When working under a specific timetable, it is important that the team remains well-informed. If a problem arises on one part of a project, it can negatively impact other parts as well. Communication should also be focused internally within the organisation. Listening to stakeholders and paying attention is a very important ingredient for success.

Good communication also includes knowing when to say no. A project team should never promise anything they know they can’t deliver. Saying no in the beginning could save unnecessary problems later. Always be honest about what your team can do and when it can be done by.

It is the project manager’s job to ensure that everything runs smoothly on a project, but having a great project manager doesn’t guarantee a successful project outcome. The entire team paying attention to key factors is what will help lead the project to true success. This success will then lead to proactive, organized project plans and an increase in quality of all future projects.

E – Executive Support

The importance of obtaining executive management support for business critical or customer projects cannot be underestimated as the executive sponsor is ultimately responsible for the outcome of the project.

In numerous studies it has been identified that:

  • The most successful projects have quality executive sponsors with expert vision and  prompt responsiveness
  • Projects with inspirational executive management support outperform projects that lack inspiration
  • Visionary executive sponsors who enlighten their team have a higher rate of success.
  • Strong and decisive executive sponsors increase the rate of project success
  • Teams that have small and large accomplishments celebrated by executive management continue to meet and exceed project expectations
  • Most failed projects lack quality executive support.
  • Non-responsive or mediocre executive support increases the chances that a project will experience overruns or failure.
  • Assigning project accountability to executive management substantially increases the chance of a successful outcome.

F – Finances

Step 1: Understand and check your budget

The first step towards managing your project finances is to understand the budget you are working to. Don’t necessarily accept the budget to be 100% accurate. I would always advise a thorough review. You need to forecast the total amount of people, equipment, materials and other expenses, needed to deliver the project. You then need to work out when in the project plan, these expenses will take place. By doing this, you can get a picture of your “project cashflow” which tells you the amount of money you need for every week in the project. Hopefully the budget will match the forecast. If not, you’ll need to escalate to your sponsor quickly and before you commence the project in earnest.

Step 2: Contingency

Understand what level of contingency budget you have to work with, if any. This is additional funding that can be used to deliver your project, if you need it. Few Project Managers actually do this in advance, but if you have almost completed a major deliverable and you suddenly run out of money, then that contingency funding might “make or break” the project. You are always in a better position to get contingency funding before you need it, rather than asking for more cash when you’ve already overspent.

Step 3: Tracking

The next step after setting your budget and securing contingency funding is to start tracking your daily spend on the project. You need to track every expense that occurs. Ask your team to notify you of any expenses incurred.

Step 4: Realignment

If you anticipate that you will start spending more than your budget, you have 3 options available to help you stay within budget:

  1. Re-forecast your expenses and present a new budget to your Sponsor for approval.
  2. Start reducing costs immediately. This means spending less to get the same job done. Or alternatively, see if your Sponsor will agree to a reduced scope, so that you have less to produce for them.
  3. Start using your backup funding to get you through the crux of the project.

Step 5: Cashflow Management

Make sure you always have enough funds available to cover your spending over the months ahead. Cashflow management is about managing the cash needed to deliver your project. So, on longer projects, ensure your Sponsor has approved the next 1-2 months of work ahead of time, and that the funds needed to manage the project have been made available. Then track the spending of that funding every week.

G – Governance

All projects involve decision-making and stakeholder relationship management at different points in the project life-cycle and at a variety of different levels. Governance provides the framework for such decision-making. The project governance arrangements must be designed during Project Start-up and will usually be a tailored blend of the basic requirements mandated by your organisation and any specific arrangements to meet the needs of a particular project. The tailoring will depend on such things as predicted benefits, cost, urgency, complexity, risk and type/quantity of stakeholders.

Project Governance provides a framework within which to manage and should cover:

  • Initial and continuing justification of the project
  • Setting up an appropriate management organisation
  • Establishing a framework for decision-making (roles/responsibilities/authorities)
  • Ensuring sufficiently thorough plans are prepared and updated as necessary
  • Implementing a stakeholder management strategy
  • Putting in place a quality management strategy
  • Setting up and operating a project monitoring and control regime
  • Managing uncertainties (threats and opportunities)
  • Managing problems and changes

H – Highlights / Lowlights and Other Reporting

Every project manager understands the importance of project reporting. Throughout all phases of the project, specific information needs to be communicated to the sponsors and key stakeholders. In a typical project, the milestones for reporting are determined in the beginning, or initiation phase, of the project. These reporting timeframes and expectations are located in the project initiation document. Clear communication is critical and will make the project manager’s job easier, as well as help the project succeed.

Project management reports can come in all shapes, sizes, and forms, good and bad.  A good project management report can set a team apart and provide valuable information to sponsors.

Regardless of the project, at least one project management report must be submitted regularly by the project manager. Often-times these reports can be as simple as updates on how the project is going, since many upper-management personnel are not interested in the details of a project. They are strictly interested in knowing that the project is on schedule and on budget and can often be a simple Highlights / Lowlights report.

At other times, they’re more detailed, involving usually six key metrics: meeting scheduled deadlines, cost, use of resources, scope changes, quality control and taking action. Most of your reports will fall into the latter group. But, they will probably all come in different formats.

Your audience is particularly important when writing a project management report. Some people will want more information; some may want less. You may have a large audience or a smaller one. Sometimes the people who are reading the reports have different technical abilities and levels of knowledge. In such cases, you should gear your writing for a wider audience. There will also be different requirements for when project reports are due therefore, it is good to get this information beforehand.

Most customers and managers are not interested in narratives and prefer reports to be around one page long. Many project management reports are simply yes and no answers with brief descriptions. You will have questions like the following: “Did the project start on time?” “Is it on budget?” or, “Are there any issues that have arisen?” As stated, when approached with these type of situations, the person receiving the information is only looking for short answers in addition to the yes or no response.

I – Initiation Document

Have you ever been part of a project where not everyone has the same view of where the project is heading? This lack of clarity can breed confusion: People start pulling in different directions, building up unrealistic expectations, and harboring unnecessary worries and fears. While it’s normal as part of a project to put the detailed plans, controls and reporting mechanisms into place, how do you get everyone on the same page to start with?

This is accomplished by creating a Project Initiation Document (PID) – the top-level project planning document. In it, you bring together all of the information needed to get your project started, and communicate that key information to the project’s stakeholders. With a well-put-together Project Initiation Document, you can let everyone understand where the project’s heading from the outset.

Your Project Initiation Document does the following:

  • Defines your project and its scope.
  • Justifies your project.
  • Secures funding for the project, if necessary.
  • Defines the roles and responsibilities of project participants.
  • Gives people the information they need to be productive and effective right from the start.

By creating a PID, you’ll answer the questions: What? Why? Who? How? When?

J – Juggling Priorities

In today’s work environments where multitasking between numerous tasks is the standard, resources often tend to over-commit by multitasking. When a resource multitasks, all tasks will take longer than if they were done one by one. If a resource works concurrently on two tasks of 5 workdays, chances are he or she will take more than 10 workdays to complete both tasks due to the effort required to “change gears”. Furthermore, the resource will most likely meet its local objectives by doing the easiest task first and the most difficult tasks last. Not always the smart thing to do!

In most organisations, when the project objectives are in jeopardy, functional managers will reassign their resources to have them prioritise their tasks in accordance with project objectives. Shorter project lead times and multitasking explain why resources working for their best interests constantly have to switch to working for the best interests of the project.

K – Kick-off Meeting

The initial stages of a project can make all the difference to its overall success, so the kick-off meeting needs proper planning and consideration.

There are four key principles for good kick-off meetings:


Productive kick-off meetings require good preparation, and your aim is to find the best ways to generate ideas and gather opinions from your attendees. In fact, don’t see it as a meeting at all – see it as a workshop. Design various exercises which guide your team members through the key questions and problems relating to the project. But keep your agenda flexible. Depending on the content that is generated, the discussions and the mood of the room, you might need to change things around on the day to keep the creativity going.


You might be inclined to only invite the key decision-makers to your kick-off meeting, but you’ll limit your project’s potential if you only hear the views from the top. A true collaborative approach is to bring in everyone who will be involved – from strategy to delivery – to shape the project. They’ll contribute valuable insight from their position, as well as getting a clearer idea of the bigger picture for their own knowledge. The exercises you design will be to ensure that everyone has a chance to provide their views.


One aim of the kick-off is to build the team’s energy and motivation around the project, and another is to make it practical. In her post “How to Increase Group IQ“, Annie Murphy Paul, wrote how the most effective teams discuss how they’re going to work together as well as what they’re going to do. Allocating some time to ask people to reflect on what works well (and not) in collaboration will help them to set up better working relationships.

Attendees will also need to come away with a clear idea of what’s happening next and their involvement in this. Ideally, rather than just distributing the meeting’s minutes, the raw notes will be analysed and developed into a document that the team can work from.


An effective kick-off meeting will be a highly collaborative experience and good facilitation makes the difference to this. Your role on the day is to encourage contributions from everyone and guide the meeting/workshop without getting involved in the ideas generation yourself. If you think this will be difficult because you are too close to the project, think about using another facilitator. You’ll need to listen and reflect back key points, organise ideas and identify themes on the spot, find out attendees’ motivations for being involved and develop this into common goals.

Bearing these four principles in mind, a few small changes to your project kick-off can make a huge difference.

L – Lessons Learned

Everything learned from previous projects, whether they were successes or failures can teach a project manager, and people working in project teams, important lessons. Individual project managers usually do learn from their own previous experiences, but are these “lessons learned” shared with others within the project team or within the same organisation? If they are shared, do other project managers apply the lessons to their own projects?

Capturing lessons learned from projects is key for any organisation. Unfortunately, project teams are usually moved quickly from project to project and capturing lessons learned is never a priority. To ensure efficiencies over time and development of best practices, it is essential to capture lessons learned on your projects.

In looking at lessons learned, many times we find things like – should have had a better schedule, or better budgeting, or more communications, spent more time on requirements, etc. All of these things relate to how we do the work, not what we work on. Talking about how things get done or working on how things get done does not, in and of itself, get anything done. This is one of the reasons so many people hate planning – planning is not doing and we all like doing.

M – Milestones & Inch Pebbles

Milestones are events within a project plan that marks the completion of a group of tasks with significance to some other group inside or outside the project. Milestones are often represented in planning tools as a project task without a duration.

Milestones are associated with key deliverables. Crucially the achievement of the milestone must represent “confirmation that the deliverable is fit for purpose”. Many projects allow milestone achievement to be recognised at publication of an unverified (not checked to ensure the development process was followed faithfully) and unvalidated deliverable (i.e.not checked to ensure completeness and accuracy). The value of project planning and tracking is severely undermined if milestone recognition is faulty.

Inch-pebbles are the smaller steps towards a milestone that assist the project manager in assessing if milestone achievement is progressing to plan. Inch-pebbles represent concrete steps (no pun intended) towards deliverables, for example requirements interviews completed or first draft document published.

N – Name and Shame Process

Unfortunately, in today’s climate of doing more with less, project members are often not full-time on a project and they often have very busy ‘day jobs’ as well as the tasks to deliver on your project. Even the best project managers sometimes struggle to use their powers of persuasion to get members of their project to deliver their tasks on time. In my career, I’ve always tried to advocate the 3 strikes process.

Strike 1 – the first occasion of non-delivery

You as the Project Manager have a discussion with the non-performing team member and emphasise the importance of the project, the strategic value and importance to the organisation, and the impact, financial or otherwise that the lack of activity has or will cause the project. Get agreement with the team member on remedial action and put a communication agreement in place, so that if there is a future risk of non-delivery or forced changes in their priorities, you will be informed well in advance of the deadline that there is a problem, so that you might be able to do something about it.

Strike 2 – the second occasion of non-delivery

Assuming that the second instance of non-delivery is a ‘surprise’ and you hadn’t been made aware of a potential slip, then a conversation with the individual and their manager is appropriate. A discussion around communication, priorities and future delivery needs to ensue.  An agreement with the team member and their manager should be reached on meeting project deadlines, and implications spelt out. The sponsor of the project should also be made aware.

Strike 3 – the third occasion of non-delivery

At this point you may have some difficult choices to make, and depending on the priority of the project within the business and the severity of the impact, you will need to consider replacing the individual with someone internally or externally (potentially at a higher cost) and delaying project delivery, which may incur further cost and other impacts such as new revenues, reputation damage or both.

O – Operational Acceptance Testing

Whether internal or external it is critical that the end to end processes for operational teams on the receiving end of a project launch have been tested and documented and that the resources involved within these processes have been fully trained and have signed off on any changes to ways of working.

Depending on the complexity and sensitivity of your project to the ongoing operations of your organisation or customer you may require a significant period of testing or parallel running to ensure that the ‘customer’ is comfortable to go fully live. All of these tests and acceptance criteria will of course have been fully agreed, well in advance of the testing taking place!

P – Planning

Fail to Plan, then Plan to Fail as the saying goes!

A Project Plan can comprise many elements, depending upon the project type, scope, technology, resources and other key project parameters.

In truth, the delivery plan should only be produced once the full scope of the project has been agreed. In some environments, this should be formally approved by the appropriate authority Sponsor / Project Board. It must also be examined rigorously from the perspective of risk . Key strategic project decisions are the most important we make on projects, and have the maximum capacity to influence risk, both positively and negatively. An example could include the partners or suppliers involved on the project – always a potential for risk.

As a minimum, a project plan should contain an analysed project schedule, a resource plan that is driven by the schedule (i.e. changes to the schedule are automatically reflected in the resulting resource plan). These elements are often referred to as the first principles of project management – sadly, these first principles are too often overlooked. The output of this phase should contain or in a sense summarise the results of all planning decisions, including risk mitigation and planning. Ideally it should also be based upon estimates that do not rely upon single point estimates of time and effort alone. Such approaches typically produce a plan that has limited probability of being achieved – something that is often refered to as the ‘happy path’….which often leads to a road of misery for Project Managers and the Project Team!

Planning must include the identification of risks to any aspect of the delivery process or the planned benefits – these can be commercial, organisational, political or any other type of risk – there are often many risks outside of those that relate to the technical aspects of the project. It is typically as sign of weakness of risk management if the only risks that have been identified are technical. Risk mitigation strategies and actions should then be developed and incorporated (integrated) into the mainstream plan.

The plan must also contain relevant processes and activities to assure that all quality targets of the projects are achieved. Again, in many circumstances this will result in an important work stream in itself.

Together, all the work streams or statements of work collectively define the scope of work of the project. In many environments this will be managed via formal change control.

The plan should be formally reviewed by all core team members and relevant stakeholders, for completeness and validity. This is then published and often referred to as the baseline plan.

The best plans also build in sensitivities, based upon those risks identified, so that a worst case, especially from a time and cost perspective can be recognised and mitigated.

Q – Quality, Cost, Time

The three most common primary objectives in project management are lowest cost, highest quality and shortest time. Very often the gain in one of these objectives needs a compromise in the other.

Time is the available time to deliver the project, cost represents the amount of money or resources available and quality represents the fit-to-purpose that the project must achieve to be a success.  The normal situation is that one of these factors is fixed and the other two will vary in inverse proportion to each other. For example time is often fixed and the quality of the end product will depend on the cost or resources available. Similarly if you are working to a fixed level of quality then the cost of the project will largely be dependent upon the time available (if you have longer you can do it with fewer people).
The astute reader will be wondering what happens when two of the points are fixed. This is when it really gets interesting. Normally this occurs when costs are fixed and there is a definite deadline for delivery, an all too familiar set of circumstances. Then, if the scope starts to creep you are left with only one choice – cut functionality. This more common than you might think, in fact its more common than not!

Top tip – The Sponsor / Board should ALWAYS be involved in formal changes to any of the ‘Holy Trinity’ – This is not a Project Manager decision to make.


RAID is an acronym which should be at the forefront of your mind if you are a project manager. RAID stands for Risks, Assumptions, Issues, and Dependencies.


A risk is any specific event which might occur and thus have a negative impact on your project. Each risk will have an associated probability of occurrence along with an impact on your project if it does materialise. An example of a risk might be that a change in legislation could mean you will have to redo some of your project and this will impact the schedule by x and cost y. As project manager it is your responsibility to ensure a Risk Management Process is undertaken, managing and mitigating risks, along with ensuring risks are routinely and effectively communicated with your stakeholders.


An assumption is something we set as true to enable us to proceed with our project or program. Typically this happens during the planning and estimation phase of the project. As an example of an assumption, during the early planning phase we might assume that we have access to skilled engineers throughout the entire duration of the project. By making this assumption it enables us to produce our plan. If this assumption turns out to be false then the project is negatively impacted. Because assumptions can turn out to be false and impact your project adversely, it is your responsibility as project manager to monitor and manage all assumptions so minimal impact to the project occurs.


An issue is anything which arises on your project which you have to deal with in order to ensure your project runs smoothly. Issues differ from risks in that they exist as a problem today, unlike risks which might turn into issues in the future. An example of an issue might be that a key project resource has left the business and it may take a number of weeks to bring in a replacement resource.


A dependency exists when an output from one piece of work or project is needed as mandatory input for another project or piece of work. An example of a dependency in a building project might be that the architectural diagrams need to be complete before the foundations can be laid. Managing inter-dependencies is critical to ensuring projects, regardless of their size, run smoothly. As project and program managers it is your responsibility to record, monitor, and manage these dependencies.

S – Scope

The primary purpose of project scope management is to ensure that all the required work and only the required work is performed to complete the project successfully. This is accomplished by defining and controlling what is included in the project and what is not.

To define a project scope, you must first identify the following things:

  • Project objectives
  • Goals
  • Milestones
  • Tasks
  • Resources
  • Budget
  • Schedule

Once you’ve established these things, you’ll then need to clarify the limitations or parameters of the project and clearly identify any aspects that are not to be included. In specifying what will and will not be included, the project scope must make clear to the stakeholders, senior management and team members involved, what product or service will be delivered.

T – Testing & Training

In my experience these are the two areas of a project that get squeezed following any quality, cost or time compromises. They are also the two areas of a project that, if not carried out effectively or at all, will cause a project to fail or to be delayed. These two areas need to be as rigorously planned upfront as any other part of the project and any contingency built into the overall plan.


There are so many different types of testing that it would be difficult to come up with a comprehensive list. Additionally, each type of testing typically has a number of variants that have been developed based on the team creating the testing strategy. However, the most common types of testing used by a majority of projects are:

Unit Testing – refers to the testing of individual software components as they are completed. This type of testing is typically completed by the development team.

Integration Testing – refers to the testing of components as they are combined or integrated together. This ensures that each component that has been tested on its own operates correctly when it is used in conjunction with the other components that it is designed to interact with. This is particularly important for client/server and service oriented architecture systems.

User Acceptance Testing – refers to testing that is performed by the user or end customer of the system or process as a condition of approval. User Acceptance Testing is where the user/customer ensures that the final application or product meets the agreed upon requirements. This is also why traceability of requirements throughout the entire Analysis, Development, and Testing life-cycle is so important.

Functional Testing – refers to testing the features and behaviour of an application to ensure that it coincides with the functional software specifications provided. This type of testing is also referred to as black box testing because it completely ignores the internal workings of the program and focuses only on the outputs as a result of the specified inputs and execution steps.

Usability Testing – refers to testing the ease in which users can learn the application, as well as the users’ efficiency and productivity while using the application.

Performance Testing – refers to testing performed to evaluate whether the system, product or process meets the documented performance requirements. Performance Testing ensures that the system, product or process will support a specified number of users / activities while still maintaining specific service level agreements (SLAs). This type of Performance Testing is also called Load Testing. Additionally, during Performance Testing, often it will be required to test the limits and determine the maximum number of concurrent users that can be supported before the system fails. This is referred to as Stress Testing.

Regression Testing – refers to testing a portion of the application that has previously been tested following a modification to ensure that the original functionality still works and behaves per the specification. While Regression Testing really just means to go back and re-test, it typically refers to Functional Testing.


Depending on the project you are managing, you may need a significant amount of training for end users, particularly if the project is introducing new software, systems, hardware or significant changes to working processes.

Whilst it is advisable to employ training professionals as part of your team, as a Project Manager you still need to ensure that the training is carried out effectively, in a timely manner and that this is signed off by the client.

Top Tips:

  1. Plan your training effort up-front, ideally as part of the business case. Know who needs to be trained, to what level and what skill levels are required to carry out the training.
  2. Tailor the training. Know your audiences and ensure that the training is pertinent to their role and department in the organisation. One size doesn’t fit all.
  3. Create Super-users. By investing extra time with a number of ‘Subject Matter Experts’ within the client or team, you can reduce the amount of in-life support you will have to cope with, as the majority of user error can be dealt with ‘in-house.

U – Understand Your Scope, Your Budget, Your Timelines, Your Team & Your Customer

As a project manager, if you can have a deep understanding of these 5 areas, you’ll be well on the way to delivering successful projects. An unwavering focus on Time, Quality and Cost, tied with a great working relationship with your teams and your customer will ensure that you keep on top of any risks and issues to your project.

V – Virtual Teams

Virtual teams are increasingly prevalent in today’s world, and a great deal of high quality information exists on how to work effectively as a team. As well as the economies that can be achieved from virtual teams, this style of project offers great potential for harnessing talent from many locations. Managing a virtual project team can be richly rewarding, and requires many of the same core competencies as managing a co-located team, with the added element of being highly sensitive to communication styles and ensuring appropriate styles are used depending on the occasion.

Watch out for future posts on virtual team working.

W – Waterfall and Agile Projects

Waterfall Project Management

Project managers traditionally identify a number of steps to complete a project, which typically must be completed sequentially. In traditional project management there are typically four stages:

  • Requirements
  • Planning & design
  • Implementation
  • Completion

Not all projects will include every stage, but most projects include elements of these stages, sometimes repeatedly as one activity relies on the completion of the last. Most complicated projects require many more stages than this, which could include:

  • Conception
  • Initiation
  • Analysis
  • Design
  • Construction
  • Testing
  • Production/Implementation
  • Verification
  • Maintenance

It’s called the waterfall method because tasks are completed sequentially..

It is widely accepted that the waterfall development model works well for small, well-design projects but can fall short in bigger, less well-defined projects that may change over time. The waterfall model originates in manufacturing and construction, where project are well-defined and after-the-fact changes are extremely costly and often impossible. It was when this model was applied to software development that its unresponsive nature became a flaw.

Agile Project Management

The agile project management model, or flexible product development approach, and is most commonly used in software, website, creative and marketing industries. In this approach project managers see a project as a series of small tasks defined and completed as the project demands, in a responsive and adaptive manner, rather than as a pre-planned process.

Agile project management’s flexible and interactive characteristics are highly relevant to the industry where it was created – software development. It’s thought that this technique is best used on small projects, or projects that are too complex for a client to understand before testing prototypes. It’s also highly appropriate for teams of professionals who work together on a daily basis. It’s much less likely to be an appropriate methodology for teams that are based in geographically disparate locations/time zones, where it probably makes more sense to implement the waterfall method.

Choosing between models can be difficult, so if you’re struggling with this question, ask yourself the following questions;

How stable are the requirements?
If the requirement of a project are likely to keep changing, its best to use iterative approaches such as agile, as it provides a framework in which new requirements can be accommodated once the project is underway. Using waterfall methods is like playing snakes and ladders; you can move forward but you can end up back at the start if the brief changes.

Are project teams working closely together?

If project teams are located far apart, coordination of work needs to be relatively detailed to avoid confusion and wasted time. In this instance Waterfall is likely to be the most appropriate method, offering clear deliverables and project milestones and dependencies. Working closely together with close communication is a key part of the agile approach, which changes and is molded each day by customer requirements.

What are the critical resources?

When projects require unique, specialist skills or equipment and these resources are not immediately available, good planning is required. If this is costly or difficult to organise, it’s important to ensure that the resource is fully utilised during its scheduled usage. For this Waterfall is a better approach, as each milestone must be completed before the project can proceed to the next stage. This will help to ensure that critical resources are used minimally and efficiently.

X – eXpectation Management

Accurately mapping expectations requires skillful listening and the ability to decipher what’s meant, not just what’s said on projects. Don’t be afraid to enlist senior management to ask questions on your behalf. As you begin to understand your stakeholders’ expectations, they will fall into two groups: realistic and unrealistic.

Realistic expectations still need managing. Make sure you can fulfil them — then make sure the stakeholder knows you are meeting them. Your communication plan must present the right information to the right stakeholder in the right manner.

Unrealistic expectations are more difficult to manage. They are unlikely to be met, and when you fail to achieve the “impossible,” the project will be deemed a failure. Fortunately, expectations are not fixed, but exist in a person’s mind and can be influenced or changed.

The key to shifting stakeholders’ expectations is to provide new and better information.

Developing a communication strategy that brings the right information to the stakeholder’s attention in a believable fashion is a subtle art. This is particularly tricky when advising upward with the goal of changing senior managers’ expectations. (I’ll write more on this in my next post.)

Y – Your Role as a Project Manager

The skills required for a successful project manager come from every discipline. Some are basic interpersonal skills while others are more technical. Some of these skills are learned only by experiencing success and failure in managing projects.

Here is a further breakdown of some of the skills required to properly and efficiently lead projects and teams to success:

Personal Skills

  • Team work – knowing how to listen, share, cooperate and learn together as a team
  • Positive attitude – important for difficult times incurred along the way throughout the process
  • Ability to clearly articulate expectations – clearly define what is expected of team members and define expectations on your deliverables to your management
  • Manage by example – project managers must be straightforward and knowledgeable in all dealings.
  • Be direct – do not overpromise and under deliver

Technical Skills

  • Technical knowledge and skills required to complete the project
  • Depending on the type of project it may be certain computer programs and software languages

Management Skills

  • Critical thinking
  • Decision making
  • Negotiation
  • Growing and sustaining a high performing team
  • Managing budgets, costs and expenses of the project
  • Project execution and control

The skills required are many and varied. A project manager must be prepared for all situations and be able to manage uncertainty and change in a less defined environment. A project manager must lead by example and motivate all parties involved. The project manager must strive to further develop and enhance their skills so as to continue leading their team to success.

Z – Zero Hour – Go / No Go

The decision to go-live with a project is one of the most important decisions in the project life-cycle and getting it wrong can jeopardise the success of the entire initiative. Whilst the Project Manager is always under pressure to deliver within schedule, sometimes it is prudent for them to step back and delay go-live rather than risk the consequences of project failure. Project Go Live decision should be taken only after thorough confirmation of following:

  • Sufficient user training
  • Adequate product testing
  • Stakeholders approvals
  • Any security activities tested and complete
  • Resolution of critical defects
  • Mapping workflows and exceptions
  • Business processes documentation and understanding
  • Interfaces integration & validation
  • Successful data migration & validation
  • Ongoing change management mechanism
  • Testing of backups and disaster recovery
  • Clear accountability for ongoing support

So, well done for getting to the end of this A to Z! I hope you found it useful, and as always would love to hear any feedback.

About Mark Conway
A highly motivated executive with 18 years business experience in fixed / mobile telecommunications and IT Services. A strong record of delivering sales and large-scale change programmes, improving customer experience and with a proven ability to build, lead & manage high quality teams; offering strong relationship building, commercial & decision making skills, gained working in technology and telecommunications for KC, KCOM & O2 in the UK, and with BT Wholesale, IBM, Accenture, Microsoft, Deloitte, SAP and Cisco in partnership. My Blogs: Think Oak! - http://www.oakconsult.co.uk/blog Life Spirit - http://www.lifespirit.biz

One Response to A to Z of Project Management

  1. Pingback: Delivering benefits by knowing what benefits are | Doing Things Better

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

Join 5,771 other followers

%d bloggers like this: