The Project Sponsor – How good is yours?

The Project Sponsor

What is a Project Sponsor?  Simply put, a project sponsor is the clients representative on a project.

As a project manager one of the many challenges we face is working with and seeking support from the project sponsor.

The role of a project sponsor starts before the appointment of the project manager. It also continues beyond closure and departure of the project manager. Ideally the project sponsor should be a leader within the business. He or she should be empowered to make project influencing decisions on behalf of the client. The project sponsor should also have the ability to walk across corporate and functional boundaries to gain the support required.

Before the project starts the project sponsor should be clear on the work to be done, the benefits being sought for that work and the cost and risks associated with delivering the benefits. These may seem obvious but from my experience they are bound together by enforcing the “why” or raison d’être of the project. Why is the project being delivered in the first place?

Absence of a project sponsor

From experience it is common practice for large organizations to run multiple large projects and programmes concurrently. They often draw on the same pool of resources. Among those resources are the project sponsors. It is not uncommon for one person to be a sponsor for multiple projects on behalf of the business. This is not an impossible or difficult scenario to manage once the priorities are clear from the business. For the individual project managers this can be a challenge. If the sponsor has limited availability, key risks or asks for the business may not be communicated in advance of an issue becoming real.

The project is being delivered to either solve the current business problem or to deliver a specific value of benefits for the future state of the business. Therefore if the sponsor has been assigned to the project the sponsor should support the project and hold the project manager and project team accountable. Sounds simple but this is often not the case.

As multiple projects reach high levels of activity, the priorities become difficult to manage for any organization. The project manager needs to shout loud enough to have their concerns voiced. Any risks need to be made visible to the main project stakeholders.

The role of the project sponsor cannot be completely separated from the role of the project manager. Both roles must work together to establish a robust process of communication from the start of the project.

A Good Start

The project sponsor and the project manager need to work closely together to ensure that the objectives of the project and the needs of the business are being met on a regular basis. Both will be judged on the outcome of the project. In many industries project managers are external consultants or contractors.  Project sponsors however are generally senior members of staff. As a project manager I always ask the project sponsor if the success of the project is a key goal for the sponsor as part of their annual performance.

Depending on the individual you are dealing with, the response can vary.If the question is posed in a subtle, professional manner there should be no issue. If the project in question is business critical then the success of the project should be included as part of the goals and objectives of the senior leadership team. (Tread carefully here)

What often follows in large multinational organisations today is that once the project has been pre-approved, set up and kicked off, the project sponsors tend to disappear. Their only interaction with the project manager is to have a brief discussion once a week on general project status.

This can result in the project sponsor believing that the job is done. Unfortunately, this can leave the project manager and project team somewhat isolated and unsupported. In addition to a regular project meeting the project manager should arrange a weekly 1 to 1 meeting with the project sponsor. This meeting should be informal in nature, face to face if possible, brief and to the point. It is an opportunity to build and develop a good relationship with your project sponsor.

Manage your sponsor

Meeting actions and minutes should be followed up swiftly and used to hold all parties accountable. If there is a pattern of cancelling meetings then it is your duty as the project manager to call a separate meeting with the project sponsor. Always come prepared. Professional people have no problem with accountability and ownership of tasks and commitments no matter what level they are at.

To run the project successfully you need the support of the sponsor. Issues may arise that require a decision by the main stakeholders. The project sponsor is your link to the stakeholders. Equally if the main stakeholders need to communicate a decision or a change request to the project team, then this information needs to be communicated formally by the project sponsor.

Be honest

If you hit a major crisis on the project or a major unforeseen event you must get this message to the main stakeholders at the earliest opportunity. Frame the issues in clear, concise language to minimise spreading panic. The project sponsor will want to know a few basic pieces of information such as:
Basic description of the issue or problem
The impact of the problem – based on Schedule, Budget and Risk
If relevant, the cause of the issue
Options going forward

Frame all potential crises in a simple form. A single slide or one page (A3 is a good method for this) will give the project sponsor the overview.When you are sure there is a crisis coming down the line, communicate the issue well in advance of the risk becoming a problem. This will give everyone involved time to absorb the knowledge before being put in a position where a decision is needed swiftly.
Openness, transparency and frank discussions are always effective for building relationships.

Play it by the book

All organizations have their own specific procedures for project management. These procedures will contain role descriptions. I recommend that you familiarize yourself with the roles and responsibilities for both the project manager and the project sponsor. Ensure that you frame your tasks and meetings around this framework.

If you are asked to do something that you perceive to be off-piste in terms of the roles and responsibilities, seek clarification from the project sponsor. If anything, this will communicate to them that you are following procedures and you are aware of your responsibilities.

In summary

The project sponsor is there to represent the client on the project and to support the project manager and project team in the delivery of the project.
The project sponsor has the same interests and concerns that the project manager does.
The stronger the relationship between the sponsor and manager is, the easier all issues will be overcome.
The project sponsor and the project manager must support each other and hold each other accountable.

If you are struggling to come to terms with repetitive project issues and you need some advice or support, contact us by email: with some background on your specific issue and we’ll be in touch.

Download our Project Team Motivation Guide Here


Essential Advice for a Project Manager

Project Managers

Many people aspire to become a project manager early in their career. There may also be a scenario where their company needs a project to be managed and therefore an opportunity presents itself. What normally happens is some training in the organization’s project management procedures followed by some formal training by a third party to receive a project management qualification. Although all training and certification in project management is important – is it enough to become a successful project manager?

What about the practical hands on mentoring and coaching required to master any skill or discipline? This is particularly important when it comes to project management. What about the person? Is the person suited to the rigours of a project management role.

Before you embark on the journey to be a project manager or before you recommend one of your colleagues here are some useful points and some soft skills that aren’t covered in any conventional project management training. These are focused on the practical side of delivering projects effectively and being a better project manager.

Choose the right team

Like any manager the ability to select the right team around you is very important. Working with people that you respect and trust can be the single most important element in effective management of any type. This only happens by understanding people, reading people and getting to know what makes people tick. Everyone is different and it is often beneficial to have a good mix of youth, experience and personalities in a project team. Above all they must respect and support each other. This may take some time to achieve but it can be a very effective culture if you get it right. The objective here is to encourage openness and transparency. A team that continually supports each other will become very effective and work well as a single unit.

Delegate everything that you can

Delegation is key to being an effective leader and project manager. You are not washing your hands of everything but you are ensuring that it gets done. Remain focused on the big picture in driving the project forward. Delegating tasks to individuals in the project team is a great way of testing people and proving that they can do the job. This is a development opportunity.
On occasion the project manager is required to roll up their sleeves. However, if this becomes a habit or the norm, it can be detrimental to the project and to your own development as a project manager.
Delegate where possible. It will keep your workload clear and provide you with the space to handle unplanned events which are commonplace on software projects.

Avoid meetings

There is a common trend in industry today where meetings take up a huge part of your working week, leaving a project manager with little time to actually get the work done. Think about the process. You attend a meeting and take an action.The more meetings you attend, the more the actions you acquire. At the end of the week, time is limited in which you can actually complete those actions. One week runs into the next and so on. The “To Do” list gets bigger and your time remains limited.

In an operational environment this can be manageable but in a project environment where you have a fixed time to complete the job, this can be a serious distraction particularly for the project manager. Meetings can drain your time and your energy and become a huge distraction from the objectives of a project.

At the beginning of a project set out the required governance and touch points. Be as practical as possible here. Why arrange a 1 hour meeting when you can give an update in 15 minutes?

There will always be a need for meetings but they should be brief, to the point and useful. If asked to attend a meeting that is not part of the regular project schedule, always challenge. When the invite arrives in, ask the questions – What is the objective of the meeting? What do you need from me? As the project manager am I needed for the full duration? Can I send a delegate in my place?

Avoid falling into the trap of multiple meetings that often go over the same ground. You must continually assess each meeting by asking – how will the project benefit from this meeting? Is it a priority over my time now?

Be good to your team

As the project manager one of your main functions is to protect your team. Protect them from politics, noise and distractions. Communication is key here. Insist on knowing all risks and challenges and assess these risks at the earliest convenience. (There is a fine line here between doing the right thing and encouraging whiners that can cry wolf on a project)

Ensure that your team are confident that if all issues are made transparent and there is no attempt to hide anything then you will support and protect the team through thick and thin. (Moving back to the delegation point here – you will not have the capacity to protect your team if you are continually bogged down in tasks that you could delegate.)

As project manager avoid being petty as a leader. If you spot a potential trap coming down the line, inform them discretely. Never take anyone on or vehemently challenge anyone in front of their peers. If you have an issue to discuss, always do this on a one to one basis. You will both appreciate it in the long run. They will learn to trust you more because of this.

A project manager should also ensure that each member of the team understands the contribution that they make to the project is valuable. Project teams are bound together by understanding that they have a contribution to make to a bigger goal than their own work. See our recent article on project team motivation Here

Talk like there is someone watching and listening

When discussing anything project or work related always talk like there is another person watching and listening. If your meeting was played back you, how do you want to perceived?
You must always come across as a professional. You should become disciplined in speaking like this in all professional discussions. It helps to build a very positive habit, one you will only acquire with practice.

Keep the ship on course

Avoid getting bogged down with every detail of the project. Leave the detail to the experts, the technical gurus and the business analysts. A project manager needs to stay focused on the key performance indicators of the project and the end game. The captain of a ship does not keep the ship on course by working in the engine room. The captain does most of his work on the bridge where he or she can maintain a clear view of the entire operation.

Over the course of my career I have observed that the most effective leaders and project managers generally only have 1 item on their desk at a time. Their workspace is uncluttered so they focus on the issue at hand. Each issue will have his or her undivided attention.


In summary an effective project manager will do the following:

1. Choose the right team around them
2. Avoid unnecessary meetings
3. Protect your team
4. Talk like there is someone else listening
5. Maintain a long term view to keep the ship on course

If you are struggling to come to terms with repetitive project issues and you need some advice or support, contact us by email: with some background on your specific issue and we’ll be in touch.

Download our Project Team Motivation Guide Here

project management

Controlling Project Scope and Preventing Creep

Project Scope Creep

Although my organization specializes in the rescuing and salvaging of troubled or failing projects, we spend a lot of time reviewing performance and results to understand where the project when wrong in the first instance. Saving a project before it needs to be saved is a much more positive experience than arriving in to try to rescue a project that has already clearly failed. Project scope creep is a major contributor to the failure of projects. Worst case scenario is that the project cannot be rescued.

One of the main causes of failure is scope creep. This is the slow but steady of expansion of the original scope of work without proper management of that scope. Management of the scope and management of the requests to increase scope are crucial if you are to be successful as a project manger.

As a Project manager have you ever been in apposition where you find scope creep has slowly started to have an impact on your project and the ability of your team to deliver on time and on budget?

How Scope Creep Starts

Verbal requests and meetings or water cooler conversations can often find you subconsciously accepting extra scope into your project.

This is particularly prevalent in software projects.
“Can I have another screen that……….?”
“Is it possible to have another field or value in that report that……?”
“Could you visualize that trend here……?”
“My team needs to have access to ……”
These will all add to your burden as a project manager.

This may be an important client that you do not wish to upset AND if it is an early engagement in the client /supplier relationship you do not want to come across as completely rigid.
If your default response is “No”, you may come across as negative and non co-operative.
This type of dilemma faces software and system project managers on a regular basis across all industries.

Project Scope Creep First Response

You need to fire the burden of work back onto the requester. (Often when you give the “easy rider” people work to do, nothing will happen!!! These are the people that make generic statement during meetings that have no basis other than to derail your work)
It is too easy for someone to state that they need something else included in the scope of work that they had not anticipated at the beginning when developing requirements. The easier you make their life, the more likely they are to keep making your life difficult.
Through trial, error and experience we have developed the following approach for responding to and managing such requests.

Project Scope Creep Questions

This is a simple response followed by a set of 4 direct questions.

Let us consider this request against the original scope of work and we will run it through the process of Project Change Management to see how we respond and manage this new information. However, before I do that we need to understand the following information:

1. What are you trying to achieve?
Please provide a written detailed description with graphics of exactly what is required. One of our Business Analysts can assist you in putting this together once you are clear what is needed.

2. What is the business requirement?
Business projects are typically executed to serve the needs of the business and therefore for every requirement there should be an underlying business issue being resolved or a need of the business being addressed.

3. What proof is required that will indicate that this requirement has been satisfied?
Software systems projects typically incorporate a User Acceptance Test whereby the vendor and the user can verify that the system serves the needs of the business and operates as expected. Both happy path and challenge tests should be considered here.

4. What are the steps, effort (and therefore cost) required to achieve this deliverable once the need is understood?
From the user perspective, they will need support from the project team to understand this impact. Involving the requester in assessing this impact is a very effective means of providing insight to the design and development process without being secretive. You will come across as being transparent.

These 4 questions if answered honestly will provide you with enough information to allow you make a clear assessment of the impact of what is being asked. You will also come across as structured, disciplined and professional.

Be careful not to fall into the trap of getting into arguments that you cannot win. i.e. this is too expensive, this was in the original scope etc. Keep to the facts and it is difficult for anyone to argue.

Project Scope Creep – Protect You and Your Team

On many occasions, I have had a finance director telling me that my estimate for the project was far too expensive only to find that they had no basis for the statement when challenged. I normally answer that statement with “We are expensive compared to what?” or “What is your expectation and what is the point of reference for this amount?” Always make a concerted effort to come across as non-confrontational. In many organizations confrontation is non-productive and only delays the inevitable. The inevitable in all instances of disagreement is that people come to a compromise and work together in order to move on.

Project Scope Creep Conclusion

Project management is a contact sport and it is not for the faint hearted. This doesn’t mean however that you need to get badly injured every time you “lock horns” with an adversary (someone trying to make your project more difficult). Rugby can be a brutal contact sport but some of the most skillful athletes emerge from most games unscathed.

If you apply the approach described above I can guarantee that it will yield results.

If you are interested in further information you can download our Guide to project rescue here.

Need help?

If you are struggling to come to terms with repetitive project issues and you need some advice or support, contact us by email: with some background on your particular issue and we’ll be in touch.

Download our Project Team Motivation Guide Here

The PM v BA on a Project

The PM Role and BA Role on a Project

One of the main challenges in setting up a project is defining the roles. No two roles’ boundaries are as close and in some areas overlapping as the roles of the Project Manager and the Business Analyst.

Both the PM and BA play leadership roles—the PM for leading the team and delivering the solution and the BA for ensuring that the solution meets the business need and aligns with business and project objectives. And both roles, equally, are required for project success.

Business Analyst and Project Manager Comparison

I have a hard time deciding whether “versus” is a good word to compare the two roles. On one hand, the project manager and business analyst should be working collaboratively. On the other hand, the two roles do offer a healthy contest in project related decisions. The issue at hand is that there is a lot of uncertainty about the difference in these roles. The result of this uncertainty is cases where one person plays both roles without enough skills for each, and other cases where the team members do not know who is responsible for what. Hopefully, we can clear this up.

The core of the difference is in the title.
The Project Manager manages the project – “The application of knowledge, skills, tools, and techniques to provide activities to meet the project requirements.”
The Business Analyst conducts business analysis – “The set of tasks and techniques used to work as a liaison among stakeholders to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to meet its goals.

Analysis of PM Role and BA Role

Stakeholder analysis is one good example of collaboration between project manager and business analyst. The business analyst focuses on stakeholders specific to the requirements and scope of the project. The project manager is looking beyond this to stakeholders whose interest is outside of the project scope. Perhaps the project manager is recording a competitor as a stakeholder to aid in the identification and tracking of potential project risk. The stakeholder analysis is a joint effort. Assign items resulting from the stakeholder analysis to either the project manager or business analyst based on stakeholder interest and influence.

Another point of confusion is in the PMBOK® task of Collecting Requirements. It looks as though the project manager is responsible for collecting requirements. When you look further at the PMBOK® tasks you also find Quality Control, yet we know the project team has members responsible for product quality. The intent of the PMBOK© is that project managers take responsibility to ensure activities for collecting requirements are covered in the project management plan and monitored along with the project. Not the project manager collects the requirements.

In either case the boundaries of the role definitions are often blurred. In any professional environment, I would expect that the Business Analyst can manage a small project if the need arose. Equally I would expect a Project manager to be able to stand in as a Business Analyst on a temporary basis or on a short assignment.
I would encourage this practice as this will give either discipline a strong sense of what it is like to walk in each other’s shoes. You will also build a team that is structured but flexible.

Project Management and Delivery

The PMBOK© and the BABOK® will not in themselves get a project delivered but they provide an excellent point of reference for organizing activates, managing people and creating schedules. The administration system behind these two BOKs is extremely effective in laying out a project at the onset and in running the project and reporting on progress.

People deliver projects, we mustn’t forget that.

I would love to know your thoughts on this topic.
Need help?

If you are struggling to come to terms with repetitive project issues and you need some advice or support, contact us by email: with some background on your particular issue and we’ll be in touch.

Download our Project Team Motivation Guide Here


The Project Mindset

The Project Mindset

I have been thinking about this topic for many years. Is the Project Mindset real? Is there a culture or a set of habits or behaviours that can define the Project Mindset?
What makes some people more suited to projects than others?
What are the traits to look for when selecting a team for a project that may not necessarily have direct project experience?

What basic knowledge sharing can happen so that the team members understand the project culture? Is this more intuition than knowledge?
Can operations and support staff run projects successfully? This scenario is becoming more prevalent in industry as operational staff in many organizations are increasingly expected to work on projects as they have intimate knowledge of the business processes impacted. Although operational targets are similar – they tend to be repeated so the team know how to achieve them and improve how they are done.

The Project

When we look at a project in general and key elements of a project, here are some of the ways in which a Project can differ from an operational environment.

• A Project has a beginning, it is not a pre-existing entity.
• A Project has an End – once the scope is delivered the project will finish.
• A Project is a temporary state – it will not continue for ever. Project teams, Rooms and Ways of Working are temporary.
• A Project is unique – even if the project is being delivered as part of a wider programme – this project is unique to this team, this site and this installation. The same project will not be repeated.
• A Project is generally not part of business as usual. Processes, documents, tests systems are needed outside of normal business. Sometimes these need to be created.

Project Resources

Looking at the above features. The First two items, i.e. the Project has a beginning and an end are obvious to most people and need no explanation or introduction.

The other three elements Temporary State, Unique and Not Part of Business as Usual create some of the biggest challenges for Operations or Support teams that are suddenly thrust into projects or find themselves on a project team.

Operations and Support teams are used to routine. Each week looks and feels that same, standard work practices, standard activity and a fixed meeting schedule for each week.
Project activity will vary as the pace changes from Kick off to Specification to Design to Build to Test to Qualification and into the Use phase.
Witch each of these project phases comes a different challenge, a different pace and the ability of the project resources to adjust the pace and change the level and type of activity is critical to the success of the project. This change of routine, pace and activity is what most operations based people can tend to struggle with for the first time they are working on a project.

Project Culture

A Project Manager or engineer with years of experience will instinctively know when to adopt a different pace within a project whereas the operations resources will just become comfortable with a way of working.
When the pace needs to change and changes some of these resources will adapt and deliver even if they are moving out of their comfort zone. Personally, I have always encouraged people to keep learning and to feel out of that comfort zone from time to time – this experience will promote the growth of the individual.
As project leaders are we best to avoid this or to address this? Is prevention better than cure? i.e. If we know that someone has no project experience should we consider them for business-critical projects at all?
Or should we offer them advice, coaching and support to facilitate the transition from the “non- Project “ to a “Project” way of working. Are people capable of adopting the “Project Mindset”? This is an opportunity for you to develop as a leader by coaching someone into a position of confidence in their new role.

Team Selection

When selecting Operations based resources for projects the above items need to be considered.
Is the person suited to a change of pace, change of activity change of routine? Just asking the person directly may or may not yield the correct answer. You need to do a little research on the individuals as you would when recruiting for any role.
Find out if they have a track record of adopting change into their daily work. How have they responded in the past to new company policies, procedures, processes and systems? How have they responded to pressure situations in the past or to last-minute changes of direction?
You need to do your research when hiring project resources for several reasons but above everything else the biggest constraint is time. As projects generally have a fixed planned duration you may not have the time to take a risk on a resource.

In Summary

Moving from operations to project based work should be seen as an opportunity to grow as an individual and expand the capability of the person and the organization.
There no hard and fast rules to selecting project resources but I look for the “Project Mindset”. I define this as a set of characteristics that will provide an indication of how a person will respond on a project.

How I summarize this is:

1. The ability to cope positively with change
2. A willingness to dig deep to complete a milestone
3. Does not tend to knee jerk react to every surprise that is encountered on a project
4. The Capability to move roles and/or work multiple roles to get the job done
5. The ability to switch off and chill after a period of high intensity working
6. Must not take any work-related discussions personally
7. Can keep focused on the end goal
8. Believe the end goal is possible
9. Can support the team to deliver the scope at all costs

Sounds easy, doesn’t it?
I would love to know your thoughts on this topic.
Need help?

If you are struggling to come to terms with repetitive project issues and you need some advice or support, contact us by email: with some background on your particular issue and we’ll be in touch.

Download our Project Team Motivation Guide Here

project management

Project Updates and Status Reports

The Report

No matter what size or type of project you are involved in in or managing, there is inevitably a status report required and update or steering meeting planned regularly.

There are numerous sources and recommendations of format, content and process of project status reports but these.
All organizations have their own preferences when it comes to style and format but the essentials don’t really differ from company to company.

The project status report must have a purpose. The first question to as is “Why?”
Some PMO (Project management Offices) in organizations sleep walk with their various templates and formats for these reports but ideally, they should be reviewed regularly.
The project status report is an essential element of Project Governance and control. Typical contents can include but is not limited to:

Current Status against Plan
Recent Activity
Planned Activity
Budget Performance
Resource allocation
Risks & Challenges

Within these headings all areas of the project can be discussed.

In addition to a communication of status this is also an opportunity to high-light any areas of concern and seek guidance, advice or support in the resolution of issues.

This may seem obvious but these meetings work best when a policy of openness and honesty is adopted.
Regular status reporting is necessary to be an effective means of communicating on all aspects of the project. It helps to maintain traction and visibility for the project. The frequency of reporting is often a function of the duration of a project and its importance to an organization. For projects with a short duration (i.e. less than six months), it is better to have weekly reporting so that issues are raised and dealt with sooner. For projects with a longer duration, bi-weekly or monthly reporting may be more suitable or desirable. As the project nears and end or a period of high activity the frequency may increase somewhat as required to manage that activity.

Project Report Content

When preparing the content, think for a minute before just blindly filling in the detail. Look for the reasons why the stakeholders may want certain information included in a report.
What is the next significant milestone?
Are there any blockers in the way to achieving the milestone?
Is the process to achieve the milestone fully understood?
Where there any contentious issues at the previous meeting – have they been resolved?

Remember that a project has been set initiated by a business to assist the business in achieving objectives or to reduce risk or resolve an issue. Always try to gear the project update into how close you are to making those business objectives a reality. This would by “Why” the project was initiated in the first instance.

Is there any important factor that needs to be discussed that is not included in the regular format of the project update meeting?
Be sure to raise it. If you are going to raise an issue it is always a good idea to have a solution or proposed way forward to present for the stakeholders to approve.

Delivery of the Project Status Report

The delivery of the Project status report is generally in the form of a meeting. These can be face to face meetings or web based meetings. Both have their advantages and drawbacks.
Face to face meetings are a great way to engage and build strong relationships. You can read the facial responses and body language and adjust your presentation to suit.
Web meetings force people to stick to an agenda and provide each participant with a specifc time slot – but talking over each other can have a negative impact on the meeting.
It is important to be clear and concise on all points to which you are presenting. Don’t say anymore that you must on any point. You may have someone in the audience who is out to impress and you or a project you are working on could be their target.
Limit your answers to yes or no and keep the detail to a minimum.
If you have some items you are uncomfortable discussing – then start with these and prepare a position on each of them. i.e. – What would you not like to be asked?

Format of the Project Status Report

Typically most organizations will utilise a format or a template whereby it is required to complete certain fields weekly for presentation to a steering team. In a new organization, it will always take a bit of time to get used to company jargon and pinch points. Don’t consume yourself too much with the template being used. This is unlikely to change in the short term so make your content suit the fields in the template. Too often I see Project managers complaining and wasting time on the report template when it is fixed and not changeable. Focus more on the facts of your project. You can always add in a comment verbally at the end of your presentation if needed. If you are asked to create a format then let the facts shape the format, do not let the aesthetics of a neat format guide your update.

In Summary – Project Updates

1. Preparation is Key.
2. Ensure your Finances, Risk Log and Activity Records are Up to Date.
3. If needed – speak to one or two of the stakeholders in advance of the update to float any potential sticky items past them.
4. Rehearse your Update in Advance (if you are expecting to deliver bad news – rehearse with a colleague)
5. Be Frank, Open and Honest.
6. Address any questions with short closed precise answers.
7. Don’t be afraid to ask for advice and Support.
8. Remember as soon as a project issue is identified – you can commence to work towards a solution!

Need help?

If you are struggling to come to terms with repetitive project issues and you need some advice or support, contact us by email: with some background on your particular issue and we’ll be in touch.

Download our Project Rescue Guide here Project Rescue Guide


The Impact of Pharmaceutical Serialization in Your Organization

Pharmaceutical Serialization

Serialization in the pharmaceutical industry requires the individual identification of each individual saleable unit. i.e. each vial or syringe or pack of tablets must have an individual serial number identifying the pack back to source, date and time of manufacture providing full traceability.
Previously legislation only required products to be identifiable to a manufactured batch which can consists of thousands of units. The imminent Serialisation legislation will require new capabilities to be implemented across many different functions of a typical company resulting in a wide reaching programme of business change.
The objectives of Serialization are:
To Prevent the introduction, distribution and use of counterfeit medicines in the global market
To facilitate the detection of counterfeit medicines
To Provide accountability for the movement of products by the supply chain participants
To improve the efficiency and effectiveness of recalls

Business Areas Impacted by Serialization

There is a significant impact on Packaging operations where serialisation data will have to be applied to product packaging at one or more levels. In the more complex serialisation models, this operational impact will extend into the distribution operations in central and/or local markets, where information on individual sale and shipment transactions needs to be gathered and added to the serialisation information. Particularly in the more complex track and trace models, significant IT capabilities will be required to manage serial numbers and track information related to the product and its movement.

Other impacted business areas include:

Supply chain
Quality assurance and control
Regulatory affairs

All these impacted areas need to be assessed for adoption of serialization and the appropriate solutions put in place. Given that these impacts affect many different functions and third parties, there is a high risk that solutions will not work well together unless the design of the overall solution is carefully managed and governed.

Managing Implementation of Serialization

Establish a programme of activity to build organisational and extended supply chain capability.
Be realistic about the emerging nature of these capabilities and build in adequate time and resource to effectively test and iterate solutions.
Design serialisation activities to closely couple related actions to minimise the possibility for errors due to abnormal events.
Design both the normal processes and the regularly occurring non-standard events to avoid product supply quickly grinding to a halt.
Ensure cross-functional teams are established to carefully design the interfaces between departmental and organisational boundaries.
Ensure adequate time is allowed for packaging design changes to be made to accommodate serialisation features required.


As with any other key element of the business. There should be a local senior level sponsor that will take complete ownership for Serialization on site or within the organization. A common misconception here is that it needs to be an IT or a Software discipline that should own Serialization. Serialization is a supply chain solution and function but the means of delivery is via Software and Technology. The ownership should be with the Supply Chain team. One could argue that all departments are in the supply Chain in some capacity. Serialization is a key differentiator in the Pharmaceutical industry and is only in its infancy. The spread and impact of Serialization will continue to grow. A dedicated team will be needed to both implement sand run Serialization as part of the daily work on each site.


Deliver Serialization into your organization with an eye on the market for the next 5-10 years not just to get a system in place.

Assign a senior level owner for Serialization.

Build a cross functional Team with the capability to manage and expand the footprint on Serialization within the business.

Ensure the Success of Serialization in the business forms part of the indivdual and collective goals and objectives for the team.

Respond swiftly and decisively to Regulatory requirements

Implement and practice the same level of control that is in place with other site systems.

For more Information and Guidance on the Implementation of Serialization please email is at

Download our Project Kickstart Guide Here

project management

The Challenging Ones and How to Manage Them

Trying Times with Difficult People

At some stage in your working life you are bound to come across the challenging people, the ones that are not cooperative and are sometimes downright difficult. This perspective of someone is generally defined by their behaviour.
This can include but is not limited to:

Disrupting Meetings
Taking Everything Personally
Not co-operating with anything
Getting in the way of progress
Not supporting the rest of the team
Delaying Projects

Like all challenges you will face – people challenges are no different. You need to get to the nub of issue.

Thinking about How to Manage Challenging Teams

The person in question has a reputation for negative behaviour. A reputation can only come from frequent consistent behaviour. If the behaviour is consistent then the behaviour is predictable. If you know how the negative behaviour is likely to manifest itself, then you can plan a response to that behaviour in advance of a meeting or encounter.

Planning to Manage Difficult People

In order to effectively manage negative behaviour or a negative reaction to something we need to pin it down to exactly what it is likely to be so if you really want to make progress, follow this approach.

1. Identify the behaviour you wish to challenge – i.e. during a meeting what is the most likely outcome. If the person has a consistent way of behaving – what is that specific issue? What is the trigger for this? Hot heads tend to have a trigger point around a specific topic that will trigger an outburst. If you are aware of this trigger then you can plan for it.

2. Once you have identified the negative behaviour, plan the response. Never react. Respond. A response has generally undergone some thought or planning.

3. If you haven’t already tried, meet with the person one to one. If that has not been productive then meet with other peers and colleagues.

4. Don’t provide any ammunition for the person to exploit. i.e. don’t start off negative looking for confrontation. Avoid leading questions that gives someone room to ramble and rant. Ask only specific topic related coherent questions, questions that only require a yes, no or another specific short response.

5. If you are looking for help, try to ascertain and get the person to state publicly if they “can’t” help or if they “won’t” help. If they can’t help, then what is the obstacle preventing this? If they won’t help – then ask why? Often you can tease out a personal grudge by asking this question. The answer will normally portray to everyone else that they are not behaving professionally.

6. Always be conscious of your and their rank and position within the organization or project. Keep the context of the situation in mind. All issues can be viewed from a number of perspectives.

7. If they decide to vent in the meeting, let them vent. Don’t respond until the venting has completed. Then calmly and clearly restate your view or perspective if appropriate or if needed for clarification. You may also need to ask for clarification on what was said during the rant. Choose your words carefully -ensure they are neither negative nor confrontational.

8. Always remain in control of what you are saying and how your are saying it. Make every meeting count.

9. Once the meeting has ended, issue minutes and actions immediately. The sooner you release them after the meeting, the more accurate they will be and the more likely people are to review and respond.

10. Stick to the facts, never get personal. Even when others may behave unprofessionally – don’t use that behaviour to combat that behaviour.

In Conclusion

After several meetings and encounters where your behaviour is consistent and professional, where all minutes follow swiftly on and are accurate. After numerous encounters where you don’t give negative behaviour any similar attention, the difficult person will identify your positive behaviour and will eventually learn to behave themselves in these scenarios. If they don’t learn then they will disappoint in other areas of there working life and eventually be exposed as not performing in some other area.

Whether you are in an operational, sales, support or project setting, negative behaviour can be managed. You can’t control how others behave but you can control your own response to this behaviour. Stay Positive.

Need Help? Contact us Here


If you’re interested in reading more about this and other topics – visit our Blog page or contact us Here


Download our free Good Management Guide – Click Here


CAPA Management – Part 2

CAPA Management Part 2 – Continued from CAPA Management Part 1

Corrective Action Objective

To generate a plan of action that will that will eliminate or reduce the incidence of the root cause of the deviation, failure, or breakdown.

Developing the Corrective Action

Consider the following elements when preparing and documenting the corrective action plan
•Decide the means to implement the action
–Process changes
–Training or Retraining
–Implementation of automation or new equipment

Decide on the implementation timeframe
Determine the method of CA communication
Determine staff involved in carrying out the CA

Scope Of Corrective Action

Do not expand the corrective action beyond the identified root cause unless directly linked to another factor
The corrective action must match the root cause of the deviation.
If possible, build the corrective action upon existing or known barriers.
Remember that continuous correction is not quality improvement!

Effectiveness Evaluation

The objective of the Effectiveness Evaluation is to generate documentation that proves or disproves the following two statements:
The Corrective action was completed and implemented as planned
The corrective action was effective in the reduction or halt of recurring deviations.

Verify that corrective action was properly implemented
Determine data source for Effectiveness Evaluation
Determine when to perform Effectiveness Evaluation
Determine evaluation period
Consider impact of learning curve
Determine success criteria

Who Carries out the Effectiveness Review?

Operations management is responsible for the planning, completion and reporting of the effectiveness evaluation.
Reporting of the Effectiveness Evaluation consists of documented evidence of the effectiveness of the corrective actions taken for the event.

Timeframe for Evaluation

In most cases, the evaluation should be started no earlier
than 30 days. This ensures that the staff is competent
and familiar with the corrective action submitted.
Depending on the organizational SOP, the evaluation for
effectiveness should begin within 60 days of the
corrective action plan implementation date.
Depending on the organizational SOP, the evaluation should be completed no later than 120 days after corrective action implementation.

Effectiveness Measurement

Observe staff directly involved in the execution of the corrective action alongside a small sample of other staff members (one to five) not directly involved in the corrective action.
Review source documents involved in the corrective action for one to three months post implementation. Look for omissions, corrections, or completion attributes that reflect a recurrence of the original deviation.

Staff may be interviewed individually or as a group to ensure understanding of the process
in question. Role playing exercises using corrective action scenarios may also be used
to ensure understanding.

Operations or Quality Assurance may perform a post corrective action audit to determine overall effectiveness.

Generate a presentation or internal document to ensure understanding of the process change initiated for the corrective action. Ensure that key stakeholders in the organization can articulate the problem. Run an update session with all teams and seek questions from team members about the issue and the investigation. If required make this memo part of the mandatory training for people affected. Supply a list of employees that have completed, including the date completed

For each effectiveness evaluation performed, a memo should be generated to document and summarize what was done for the evaluation and the resultant outcome.
Details including the date range, persons performing the operation, and specific root cause being evaluated should be documented in the memo.

In the Event of a Failed Evaluation

Issue a new deviation or nonconformity. The Root Cause Analysis will need to be redone.
Items to consider:
There may have been multiple root causes that were not initially discovered.
There may have been significant contributing factors that were not discovered.

To summarize an Effective CAPA Process

1. Define the problem.
2. Gather data/evidence.
3. Ask why and identify the causal relationships associated with the defined problem.
4. Identify which causes if removed or changed will prevent recurrence.
5. Identify effective solutions that prevent recurrence, are within your control, meet your goals and objectives and do not cause other problems.
6. Implement the recommendations.
7. Observe the recommended solutions to ensure effectiveness.

For more information Download our Troubleshooting and Investigation Guide here or contact us at

project management

5 Key Components of Project Delivery

Project Execution and Delivery

Weekly priorities and goals need to be set from the beginning. Set out a culture of delivery and accountability from the very start. On large projects – some team members can coast their way through the first few weeks of a project and before you know it – you are behind schedule. The success of a project is the result of the success of the day, week month and year of the project. Get the team members into the habit if self-accountability – i.e. where they tell the Project Manager what they will deliver today or this week and how this will contribute to the success of the project. This is where team selection is key – ensure that there are no passengers on the project team. People who are not contributing will suck the life and enthusiasm out of the project team and make the project harder to manage.

Utilize Project Team meetings a means of:

Communicating Status
Reviewing Performance
Making Plans for the coming week
Discussing risks and issues

This type of meeting should be held on at least a weekly basis depending on the level of activity and customer expectation. Rotate the chair, keep accurate list if minutes and follow up on actions regularly

Another function of this meeting is to gather information required for project governance to a site leadership or above site team. These updates are typically summary of the weekly project meetings. These meetings are also a means of highlighting issues and or requesting guidance and support at difference stages of the project.

At each major point in the project, e.g. after every big deliverable or milestone is complete – conduct a brief, honest review of performance, a lessons learned session to take forward any learnings into the next stage of the project.

Project Reports and Communication

Different organizations and industries will have their own requirements on the level and type of reporting and communication. There may be different templates to be managed depending on the level of reporting required. It can be useful here to only maintain a single reporting template for each project. The reporting template for each project should not become the focus of the work but should be used as a means for communication. On a project with a long duration, this can take a while to get right as the audience may vary and their weekly focus can shift from cost to schedule to risk to resources at a minute’s notice. The only recommendation here is to be honest, clear and transparent – the earlier an issue is highlighted, the earlier a resolution or support can be sought. Communication should always come from the Project Manager – and the PM should assign a delegate in the vent of absence. Stick to a consistent form of communication.

Project Issues and Resolutions

Throughout the course of any project -issues will occur. They can be technical, logistical, resource, risk, budget or schedule related. Instead of worrying about unknown unknowns – focus on what the strategy is for issue resolution. An example of this is:

1. Problem Statement
2. Probable causes
3. Impact to the Project – cost, schedule, risk
4. Conclusion or Root Cause – Where appropriate
5. Proposed Solutions
6. Recommendations
7. Support or Direction Required from Site Leadership or Above Site Teams via governance

Having a structure will help frame every problem and get the team into the habit of managing problems effectively.

Regular, honest and transparent monitoring of key performance indicators such as schedule, budget and scope will enable you to capture a potential issue before it becomes a bigger challenge to manage.

Managing Project Scope and Delivery

This is probably the biggest challenge facing project – the control of scope. The scope is agreed at the outset of the project via the Project Charter and other associated contractual documents. The detailed plan assembled before project kick off helps to clarify the definition of the scope further. With the best will and intentions – this scope will be misinterpreted somewhere along the way. Expect a dispute on one of the finer points of detail – this typically occurs when interfacing with a different system or having to manage another vendor or third party. In order to reduce the occurrence of such challenges always build risk around system interfaces and third party deliverables.

Another area where scope can increase or begin to creep is during “Corridor” or “Watercooler” conversations. i.e. someone may mention that – “It would be very useful to have a report on this new system that showed Purified Water usage on a Daily, Weekly and Monthly basis.” The statement may be true – but if is not in the original scope – it is not in scope. To some end users – statements made during conversations are a contract, an agreement by the project delivery person to include this requirement in scope and deliver it with the original scope of work.

Many organizations have procedures for Project Change Controls and managing extras. This may indeed be a legitimate business need but the original project costing and plan – it is not in scope. In order to include this requirement in scope the following must happen:

1. The end User or Client – Completes a project change request
2. This is assessed by the technical SME
3. An Impact report is produced in terms of Time, Cost, Risk
4. The end user accepts this proposal
5. The change in scope is approved at the Project Governance forum
6. The new requirement is included in scope and the original contract is amended accordingly.

Different organizations will have variations of this process but essentially the process must be respected.
There may be more simplistic examples were for the sake of good customer relations or lack of clarity in interpretation of requirements – a decision is made to absorb a change request into the original scope of the project particularly where the cost and time involved is negligible and will not impact the original delivery budget or schedule.

As a default position – it is always best to utilise the process that is in place as a starting point.

Project Closure

A common oversight in industry today is the effective and complete handover of a system and closure of a project so that all legal, financial and logistical obligations are discharged and recorded correctly to enable a project to close completely.

Before closure it is wise to conduct a review of project delivery against actual performance and original intentions. This can include the learnings carried forward from earlier stages. It is also important to acknowledge any challenges experienced and that you have implemented measures to ensure that a recurrence of the same issues is greatly reduced or eliminated. Items covered should be –

What worked well?
What needs improvement?
What should we start doing?
What should we stop doing?

If you happen to do business with the same customer or end user again – theresulting report is always a useful starting point.

Other items to be considered at project closure:

1. Any warranty obligations are have been honoured
2. A support agreement for operational support has been set up
3. All items within the project scope have been delivered
a. Documents
b. Procedures
c. Test Results
d. Training Evidence
e. Software Versions
4. All contractual obligations on both sides have been agreed and closed off

Project closure generally takes some time but this can be formalized with a meeting between all stakeholders to gain official agreement and consensus that the Project is now closed.

Need help?

If you are struggling to come to terms with repetitive project issues and you need some advice or support, contact us by email: with some background on your particular issue and we’ll be in touch.

Download our project rescue guide here Project Rescue Guide