Project Managers need to be leaders not administrators

Project management is about getting the job done, not pleasing the PMO

Lately I’m hearing more and more complaints from experienced project managers because they are being used as expensive typists and spreadsheet crunchers to keep the PMO happy.

Some companies are not seeing the difference between effective project management and administrative project management. PMOs are supposed to support and facilitate project management but more commonly I am seeing the opposite. PMOs are actually burdening projects with plenty of “non-value add” and energy sucking administration for the sake of it. This practice is sadly endorsed by an increasing number of organizations.

Recently I sat through a project steering meeting where company executives criticised a project manager for not using the correct version of the spreadsheet template for the steering update. They failed to acknowledge that the project had been performing very well in all areas, and that the PMO had updated the template only the day before the steering meeting and had expected everyone to be aware of this fact, although they informed nobody. The PMO then jumped on the band wagon about the importance if using the correct template. I find this type of experience painful.

Project management is not just project administration

There are basically two types of project managers – administrators and real PMs. Administrators are the PMs that document and report infinite detail on progress and project results (most often of failure) in project plans, status reports and other documentation. Real effective PMs, are rare. These are the people who can make the desired result happen. They deliver the news rather than document and report the news.

They are leaders first and are relentless in their pursuit of project milestones and completion. They are unafraid to speak up, stand up, and confront when needed; indeed, they are willing to surface issues quickly and get issues the attention they deserve rather than letting them silently kill the project. They accept responsibility, demand accountability, and won’t take no for an answer. They work tirelessly to go over, under, around and sometimes through obstacles. Through their own endeavours, they create teams of people with that mindset. They focus on the goal, not the process.

These PMs understand that the customer stakeholders really don’t care about how hard you work, or how perfect your administration skills are, they only really care about what you deliver. This is not to say that administration should be ignored, it just should not become the project. Many organizations are failing to point out this difference to their PMs and PMOs.

Project management way of life

Project management is a contact sport, and not for the faint hearted. Effective PMs are strong leaders by their nature. Paperwork and processes should support the project and enable communication within and outside of the project team. Every document created as part of a project should add value and serve a specific purpose. Too often in industries such as Life Sciences, a myriad of documents is created to support project delivery. Many of these are mandated by the regional regulations, many are not.

stakeholders really don’t care about how hard you work, or how perfect your administration skills are, they only really care about what you deliver

Administrator PMs blindly walk into these document mountains and never question the purpose of each document, citing the regulations as the reason. The effective PMs look at the value of document and will leverage from previous work where possible only producing a document where it has a direct or supporting part to play in the project. They ensure that only the documents required for regulatory compliance are produced.

Priorities

Project management is not for everyone. Lots of administration is not for everyone. Unfortunately, PMOs in many organizations are failing to see the difference between effective administration and effective project management. I have often experienced PMOs lecturing PMs on how projects should be delivered when many of them (PMOs) have never actually been near a real project. The are rewarding PMs that are qualified in the process of project management and failing to recognize the skills of project management.

 

Project Management points to consider

A few things that I have learned and observed about projects over the years:

Failure on a project is a temporary state (or if you are going to fail, failing fast is much better than failing slow – so get showstoppers out in the open and under discussion fast).

Your project team will do their best to accomplish (and exceed) the goal – if they are clear on what the goal actually is. If they believe they can do it, they can do it.

People get projects done, not templates and documents.

Focus on the END goal – there is always a way.

Figure out your critical resources and ring fence them from work outside the project.

Project Documentation should serve and support the project, it is not “the project”.

Lots of people have opinions and advice on what should be done…only a few can actually get it done.

Ownership and Accountability are everything. Good people don’t have an issue with this way of thinking.

NEVER plan projects using duration – effort (and resulting output) is what matters (most projects are planned using duration).

You cannot communicate too much, within the team, to stakeholders, company leadership etc.

On a related topic read The Project Mindset

For more information contact us by email: karen@systeme.ie we’d love to hear from you.

PM Terminology or Methodology

Project Management Methodology

The modern world of software projects appears to be flooded with agile terminology. Whether it is companies that claim to be at the cutting edge of agile or companies trying to catch up on the latest trends to improve project delivery, there is no escape from the seemingly ubiquitous agile approach and all its trappings.

The desperate need to change the way projects are delivered and the hasty adoption of agile have caused some problems in certain organizations. Some companies are continually breaking the corners off their own processes and project scope to make them fit into an agile model. I have seen organizations become consumed with the agile terminology, tools and buzz words and lose sight of the fact that there is still a lot of work to do. This may sound cynical but there are still the normal bread and butter mundane elements of a project from which there is no escape if you want to run an effective project. This is particularly prevalent in the area of Life Sciences.

It’s about the project

If there is a possibility that scope and priority may change because you’re working in a turbulent and complex environment maybe it’s because the requirement has not been well defined at the from the start it’s preferable to work in a more agile way where you can adjust as you go but the agile approach it doesn’t lend itself to efficient requirements gathering nor doesn’t guarantee an efficient delivery. The agile approach won’t guarantee effective requirements gathering (where most project problems begin and end)

Rather than getting caught up in the fashionable aspect of agile, it is more prudent to take time to understand the scope of work and the associated complexity. Often, a careful blend of both agile and waterfall methodology is the most effective means of delivering a project.

To GANTT or Not to GANTT

To use a specific example, at the beginning of a large project or program in industry in every organisation there is always Gantt chart assembled using a software application. There is a huge focus on the plan but rarely is there a strong focus on the planning process itself. Some organizations treat this chart as the only means of planning and tracking. Those who choose to do this often end up in trouble. I take a completely different approach to the use of Gantt charts particularly on large complex projects and programs.

The biggest error that I see made in most Industries and most projects is where the Gantt is seen as the only tool available to both plan and run a project. The Gannt contains all resources, roles and responsibilities, tasks millstones and inter-dependencies. When visiting a client for the first time I am often presented with a monster Gantt chart plastered across one wall of an office. Sometimes these contain thousands of tasks in the work breakdown structure. This issue with these types of plans is that by the time it has been removed from the plotter it is normally already out of date.

GANTT

Gantt charts provide a very effective means of understanding the complexity and the order of magnitude of a project. For example, a Gantt chart will be able to give me information on a project as to whether it’s going to be a 12 month or a 15 month or a 9 month or a 6-month project. The Gantt chart can also provide a better understanding of interdependencies within the project and the impact a specific dependency can have on the outcome and duration of the project.

Gantt charts provide a very effective means of understanding the complexity and the order of magnitude of a project.

So, when we take this into consideration Gantt charts have a valuable role to play at the very beginning of a project or if there are any major changes the project. Another important output of Gantt charts can be the resource estimation of the time skill sets required in order to deliver the project.
Once the Gantt chart has been developed (it takes several attempts to get a reasonably accurate Gantt chart of the project or program) it can then be possible to break the specific portions of the program into more bite sized chunks look at them individually. It is very important here however never to lose sight of the big picture and all the major milestones that have been defined by the Gantt chart.

Thinking Differently

Enter agile. So then we can look at the difference sections of the plan and it is here we can begin to look at the more agile approach such as Sprints run by daily scrum meetings.
The titanic shift from conventional waterfall methods to agile can introduce just as many challenges as many agile experts claim it can overcome.

Two fundamental features that constantly need challenge are:
Self-Managing Teams
No Project Manager needed

I’ve only seen this work in exceptional circumstances where all the corporate planets are aligned – i.e. company culture, innovation, high performing team members, and 100%  accountability. Regardless of the approach, a large body of work still needs to be managed.

So when we take these brief points into account, we are starting to talk about a hybrid approach where the benefits of the waterfall approach and agile approach can be realised by focusing on what you need to deliver and then choosing the best method of delivery. Being careful not to cement the method of delivery too early on the project and always leave it open to change. This will ensure that your project delivery approach is truly agile instead of it towing the agile line for the sake of it.

The “what”

In truth the method of delivery is not too important. What is important is the delivery itself. It is very difficult at the beginning of a project or program particularly one that’s never been done before, to define the exact method of delivery. On a long term (12-18 Month) project it is virtually impossible. The advice that I would give here to let the size complexity and the strategy of the project delivery define the method.One of the main challenges in industry today is massive use of jargon or the desire and use of more jargon without a good working knowledge of what the words mean, what are intended to mean and so agile within one organisation have a completely different meaning when you transpose to another organisation. Different industries will view what agile is differently too.

New Trend

It looks like Hybrid is a new buzzword on top of many buzzwords, for example agile was a buzzword concept at one stage. These approaches have existed for many years in different Industries such as manufacturing.
So although Hybrid is the new trend/fashion/buzzword, it will no doubt create another need for training, knowledge transfer and learning.
In truth when one of our clients looked at how that had been doing projects for years, they were effectively taking a Hybrid approach, they just didn’t call it anything in particular.
The purpose of a project or program should be to add value or reduce the risk to a business by implementing a new system or product. The business therefore should not see projects a something else outside of the business. The focus should be very much on what it takes to deliver those benefits to the business.

In summary

Therefore, the question should now move to how you can deliver those benefits in the most efficient way for your organization. From my experience, nobody is really interested in how hard you are working, but in what you are delivering.
The most effective method may be Agile, it may be Waterfall or most likely it could be a careful mixture of both. Don’t lock yourself into an approach too early in the project or program. Don’t be afraid to review and adjust the approach until it’s working.

On a related topic read The Project Mindset

For more information contact us by email: karen@systeme.ie we’d love to hear from you.

Projects and Dark Matter

Dark Matter

One of the biggest risks that software project managers face is “Dark Matter”. On a software project it is defined as “The entity that we know exists but cannot see”.

It is most prevalent on projects where you require an intimate knowledge of business processes. At the beginning of a project, the Subject Matter Experts are assembled, the scope of work is defined and plan is brain stormed. As a project manager we try to extract every last detail about how we will deliver the scope of work. This typically takes a number of attempts but eventually when everyone has that warm cozy feeling, we agree on the plan and kick off.

Warnings Signs

Some weeks into the project at an update meeting someone brings something to your attention, something new, or an oversight perhaps that could have been captured and planned at the original planning sessions. You take it on board accepting it’s a “once off”, you re-plan, you move on.

Two weeks later a developer or engineer sends you an email stating that they have found something else that they need to do that we didn’t capture at the early stages. You take it on board accepting it’s the second “once off”, you re-plan, you move on.

Two weeks later again a developer or engineer sends you another email or speaks up at a meeting stating that they have found something else that they need to do that we didn’t capture at the early stages. You take it on board accepting it’s the third “once off”, you re-plan, you move on.

Does this sound familiar? Are you making the developers/analysts/engineers accountable and letting them feel some of the pain you feel as a Project Manager?

Managing Dark Matter

When running large complex software project is, it is inevitable that there will be unexpected events. It is important here to distinguish the “known” unknowns from the “unknown” unknowns or Dark Matter. For example during testing you may expect to see some issues or defects that need to be managed. So, you “know” that there will be issues but you don’t know how many or the impact of them – i.e. “known” unknows. Then there are the Dark Matter unknowns – it something that someone completely missed at the planning and estimate phase that needs to be dealt with and will have an impact on the project.

When this happens, you should always ask the question, “How did we miss this?”, and “ Are there any more elements Dark Matter lurking in the background that will surface at some stage. It is human nature that in general people do not like to give bad news but it is very important to encourage the project team to be transparent about all issues or potential issues.

So back to the original question – “How did we miss this?”, could we have approached the scoping and planning phase differently? Did we go into enough detail at that time? You will never prevent all of these items, but you can certainly put measures in place to limit their occurrence.

During the planning phase when you have assembled all the relevant SMEs, and when a milestone or deliverable is identified, list all of the steps and resources required to complete the milestone. Go through the steps at least twice, leave it and come back to it the next day when people have time to think, I can guarantee that someone will add to the steps or introduce some other dependency after they have had time to think.

In GxP (regulated pharma projects) a common source of under-estimation is documentation effort.
For example it is very common to see a single line item in a document named “Design Document” with a timeframe allocated to it. e.g. 5 days.

When you look at the actual time and effort it takes it can look something more like:

Draft the Document – 3 Days
Issue Document for Review – 0 Days
Review wait Time – 3 Days
Update Post Review – 1 Day
Issue for Approval – 0 Days
Approval Wait Time – 3 Days
Approved – 0 Days
Released – 0 Days

So, in this very simple example it would seem that the actual time was double the original estimate. If a deep dive was done into the company’s procedures (and track record) for managing document review and approvals, this would have been captured.

Ownership and Accountability

If you experience a few minor occurrences of dark matter during a project, you can probably live with it. If on the other hand every time you expect to complete a task, you experience another instance of dark matter in the form of new tasks and dependencies, you need to stop, down tools and do a deep dive into the plan. Nobody will want to do this but it I necessary sometimes. Don’t however fall into the trap of follow exactly the same planning method. You will need to do something different. So allocate ownership of specific parts of the plan to individuals. Make it clear that you need their expertise to get int every detail before you can communicate out on another baseline of the plan.

Too often on a project the plan is seen as being the Project manager’s plan – it needs to be the team’s plan and they need to take ownership of their own elements where appropriate. This may be difficult at first but if someone knows that they are being judged on the quality, accuracy and performance of a plan, you will see a different response from the team. Be careful here to distinguish between blame and accountability.

When re-planning, the plan needs to be stress tested by peers and the SMEs to try to break it before you go public with it.

Summary

In summary

Dark Matter exists on software projects.
Don’t ignore multiple instances of dark matter, make the SMEs accountable.
Re-plan differently, learn from previous mistakes.
Stress test the plan.
Look for other potential areas of dark matter.

Further Reading

Other reading – Controlling Scope Creep see this previous blog here

We’d love to hear from you on this topic. E-mail us here

Creating Positive Habits for Project Delivery

Projects
From working on many projects over the years one can become accustomed to the culture of a project in terms of delivery, habits and work ethic. We can take a lot for granted in terms of what has become the norm for us.

On a recent assignment with a client we had found it difficult to recruit people with the right attitude for the upcoming body of work. We had to place junior graduates with more experienced project team members. The technical knowledge can be transferred over time and with the right attitude and desire anyone can learn how to do anything.

There is however a softer side to project delivery that is seldom written down – the ability to deliver under time pressure and maintain focus on the work at hand. The decision to give the graduates some exposure to more experienced people was not just to absorb the technical knowledge but to observe and learn the habits and attitude of delivery and the value of taking action.

Action
Projects get completed because people take action, complete tasks and achieve objectives. Taking action is fundamental to successful project delivery. In trying to get this across to some of the new members of the project team we tired to categorize the practices, attitude and habits that we need them to adopt to be able to deliver consistently in a challenging environment.

We summarized the points that we were trying to make as follows

Successful Project Teams Take Action
With a ready-fire-aim mentality, nothing beats taking action. You could pull out a great book about success and learn from the greats, but there is no better teacher than experience, which comes only from taking action. Completing a training course may prepare you for what is to come but the experience of taking action will teach you so much more and this experience will stay with you.

People can spend too much time making a decision. They worry about making the “right” decision. A former boss of mine always encouraged us to “Fail Faster” as he was convinced that this would get us on the right track earlier than and long drawn out decision making process.

Even if the action is incorrect – you will learn that it is incorrect quickly and get back on track quickly instead of extensive procrastination and risk analysis.

Completing a training course may prepare you for what is to come but the experience of taking action will teach you so much more and this experience will stay with you.

Taking action will get you where you need to be much faster than detailed analysis. When you are faced with this situation, ask yourself – “What’s the worst outcome? What is the worst thing that can happen if I take this action?”

Consistent Action Creates Momentum
When you have momentum on your side, several benefits kick in. The momentum of being “in the zone” performing any task makes the task easier to perform. Momentum can also make a large body of work appear more manageable and achievable.

As you witness yourself doing more work, taking on additional work does not seem daunting. Surprises or unforeseen issues on a project are just absorbed into the main body of work when the project team has momentum. Have you heard of the saying – “If you want something done – ask a busy person.”

To use a sports analogy, regular training for a football match will prepare you for the match but actually playing more matches affords you the opportunity to get better at playing matches.

Consistent Delivery Becomes a Habit
When you work on projects long enough and get used to consistent delivery, this can become a habit, a positive habit. This can happen subconsciously at first but if you analyse performance between a time when you were not in a high paced delivery environment and being in an environment where consistent delivery is the norm, you will notice the difference.

Some research indicates that it can take approximately 60 days to form a habit, a habit that you don’t need to think about too much – it just happens.

Habits are often seen in a negative light. Looking at the dictionary definition:

habit
Definition (noun)
1. a settled or regular tendency or practice, especially one that is hard to give up.

Doesn’t sound very inspiring does it? I prefer another definition that relates to the psychology of the word.
an automatic reaction to a specific situation.
Now that gives a more positive representation of the word. So as we stated above, where a high paced delivery and continuous execution of work is the scenario in which you find yourself – if we are exposed to this environment in the correct way for a prolonged duration – this can help to form the positive habit if you chose to do so. In acquiring the positive habit you will perform in response to the needs of the project. The same response in reverse would ensue if your response is negative and you form a bad habit,

This is by no means a new concept as the idea of positive habits defining the individual and subsequently success has been well documented for centuries. In the following passage written by one wiser than I, and shamelessly borrowed from the Talmud:

Pay attention to your thoughts, for they become your words.
Pay attention to your words, for they become your actions.
Pay attention to your actions, for they become your habits.
Pay attention to your habits, for they become your character.
Pay attention to your character, for it becomes your fate.

This passage places a huge emphasis on habits and their effect. Bringing this back to personal performance and the performance of teams it may seem somewhat philosophical but it does have some practical resonance in the working world today. If you replace the term fate for your performance. The message here is that strong performance is not an accident.
It is intentional based on your thoughts and your actions. Maintain focus on the task at hand while always keeping sight of the next milestone will ensure that your contribution to the project is positive. Thoughts, words, actions, habits ultimately define how we perform, so ensure they are always moving you forward towards the next goal or milestone and this starts with the right mindset.

Summary
Successful Project Teams Take Action
Consistent Action Creates Momentum
Momentum Creates a Positive Habit of Delivery

On a related topic read The Project Mindset

For more information contact us by email: karen@systeme.ie we’d love to hear from you.

Managing Small Project Teams

Teams

While working recently with a client, they asked for some specific advice for managing small project teams when delivering software projects.

Previously their project teams were quite large, but the nature of their work now needs small project teams completing software modules in less time. This is to enable them to support ever-changing market needs.

Their teams were used to a culture of clear role definition and never stepping outside that role even if it meant that the project was delayed. They claim that they could remain focused on the task at hand and they could specialize in a field of expertise relating to the client business.

The client knew they needed to adapt but they were fearful of the impact of this change on their operation and if it could impact what they do in a negative way.

Approach

The “large team” mindset certainly has its merits. But it only has it merits in a certain context, i.e. where there is a large team of people available. Where there are large project teams there is generally the availability to pick up the slack and reassign tasks to the next available resource. Small project teams do not have this luxury and therefore need a different mindset.

Smaller project teams can drive a different behavior and therefore need to foster a different culture to survive. In smaller project teams flexibility is everything. Although team/members still have a primary role they also have an obligation to do what ever it takes to keep the project moving. For example there is no reason why a business analyst cannot support software acceptance testing or author and review key documents.

Management

The project manager has a similar obligation when it comes to keeping things moving on a project. For example I have witnessed too often where a PM is waiting on a resource to perform a simple review task when the review task is well within the skill set of the PM.

All project team members need to keep focused on the end goal and it is one of the responsibilities of the project manager to ensure that this vision is clear and obvious to all concerned.

Project Team members (including the PM) have an individual primary responsibility but also have a common secondary obligation to keep the project moving if they have the capacity and ability to do so.

The situation is best managed by a daily touch point with the full team. At the meeting we must understand – What is the priority for today? Do we have the skill set within the team to achieve this goal? Do we have the capacity to achieve this goal? What is the impact of completing this task?

Focus

As with each person’s primary responsibility, should come secondary ownership and expectations. If anyone finishes a task ahead of schedule what should they do? Answer – they should review what else needs to be done and what they themselves can do to achieve the next milestone or goal. They should also see if any of their colleagues need any support to complete a task.

Project Team members (including the PM) have an individual primary responsibility but also have a common secondary obligation to keep the project moving if they have the capacity to do so.

The agile scrum approach is an effective means of managing such work. The work tasks are queued up in a priority and the work is reviewed daily. Therefore, a change in priority can be communicated easily. This approach encourages and facilitates regular feedback.

An underlying theme here is strong, effective, clear and frequent communication.

Summary

Small teams need to adopt a slightly different approach to large project teams and base their work on the following principles:

1. There can be no 100% demarcation of work

2. The priority can change daily

3. The task you are assigned and working on can change daily.

4. Be prepared to step outside your comfort zone from time to time

5. Project success or failure is the responsibility of all concerned

6. Encourage open honest feedback among the team

7. We all fail or we all succeed.

Set these ground rules with small project teams and review the effectiveness of your approach regularly. Deal with any issues or concerns swiftly and do not let any issues fester. The solution to most project team problems can often be found within the team itself. Encourage feedback from the team on how the project is performing. From these suggestions, don’t be afraid to experiment with tasks, you may be pleasantly surprised, but don’t take crazy risks.

Culture doesn’t change overnight, and some people are not suited to the small team set up. This is a hard reality.

Further Reading

Flexibility does not mean multi tasking. Multi tasking is a myth – see this previous blog here

One person can only focus on one task effectively at a time.

We’d love to hear from you on this topic. E-mail us here

MES Systems and Benefits

Definition

With so many different variations of MES (Manufacturing Execution Systems) in use today, it can be difficult to define exactly what MES is and how it is used. The use of the system will vary from company to company.

Manufacturing Execution Systems can be defined as systems that record and control the execution of a manufacturing process from raw material to the finished project. Depending on the product being manufacturing and the level of complexity involved, the systems can be simple or complex.

MES generally exists as the layer between the process control (level 2) system and the ERP enterprise resource planning (level 4) system.

The pharmaceutical industry is a shining example of how MES systems can be used for maximum benefit.

Since their inception, most manufacturing organizations have relied on paper records, Paper SOPs (Standard Operating Procedures) and processes to manufacture batches of product.

Although functional, paper records have numerous challenges that can lead to some major issues for the manufacturer.

1. Paper can go missing
2. Paper can get damaged
3. Hand written records can be difficult to read
4. Paper records can be easily falsified
5. There is no accurate verification of timestamps
6. Paper records can be completed anywhere
7. Paper SOPs cannot be 100% enforced or policed.

The removal of paper from manufacturing processed is a major objective of many companies.

MES systems eliminate completely the problems of paper but there is still the challenge of Data Integrity to be considered.

Regulation

For well over 20 years the worlds regulatory bodies have been calling for and providing guidance on the use and implementation of a computer system-based method of producing and maintaining manufacturing batch records.

Many organizations throughout the world have eliminated and reduced paper processed in pursuit of the many benefits can come with the use of MES. There are however still many manufacturing facilities that continue to use paper processes and records as a means of managing manufacturing.

The reasons why some companies stick with paper are:

1. Paper is tangible and flexible
2. People like the tactile form of paper
3. Out of spec or adverse situations can be managed with paper
4. Paper is cheap to run
5. MES systems are expensive to implement
6. MES can be disruptive to the business during implementation
7. Old habits die hard

What are the benefits of MES?

Depending on the use of the system, the benefits of MES can vary greatly. Some of the main benefits include:

1. Removal of paper from the process
2. Faster review time of manufacturing records
3. More accurate records
4. Time stamped audit trails
5. Recording of user access
6. Ensuring people can only follow a consistent process
7. Improved quality
8. Reduced Data Entry Errors
9. Improved productivity

The case for the removal of paper records

The case for the removal of paper records may seem obvious but there are numerous benefits for example.

Within the software system every transaction is time stamped and therefore it is very easy track the sequence and timing around each event and activity associated with manufacturing and actual product.

The main benefits of Manufacturing Execution Systems include:

• Removal and reduction of paper records (including equipment log books) for the reasons detailed above.
• Reduction in production review and quality review activities
• Ease of Batch Reporting
• Improved quality via consistent manufacturing by enforced workflows (i.e. people can only to the right thing)
• Reduce time to prepare for regulatory audits
• Improved quality metrics
• Increased transparency
• Over time improves peoples’ behaviours
• Free up man-hours for more value-add activity

Investigations into manufacturing problems are much easier when using an MES system because all activity is recorded and is a is traceable back to a specific events or conditions.

Equipment and work efficiency can be measured much more precisely with system timestamps.

Underpinning all of these advantages is the main reason for implementing an MES system and this is patient safety. That is the ultimate goal and standard.

Company Leadership Must Drive the Culture

As with all initiatives and journeys upon which a company may embark must have the sincere support of the company leadership. The manufacturing leader’s mindset is hardwired to keep production moving and keep high volumes of product leaving the plant and entering into the supply chain. This is a valuable character trait and is an essential contributor to the success of many organizations.

Underpinning all of these advantages is the main reason for implementing an MES system and this is patient safety. That is the ultimate goal and standard.

When operators are driven down the road of enforced workflows (using and MES system), i.e. they must to the right thing at the right time, as opposed to filling in paper records whenever is convenient, the initial high-level observation is that the new system has slowed down activity on the line.

While enforced workflows can indeed slow operations down slightly, is this a fair price to pay for compliance and quality? Looking at one single facet of the operation can be short sighted. A wider view needs to be taken if the full benefits of MES are to be acknowledged. Instead of measuring one single element of the process, look at the end to end benefits and savings.

In removing paper from the manufacturing process, many types of human error are removed. For every manual signature or data entry removed, a verification of that entry is removed. Hand written data entry errors occupy a huge time portion of the batch review and release process.

Given time, MES can reap many benefits but pharmaceutical manufacturing company leaders must be patient focused and not numbers focused. In these organizations, (and there are many) the leaders make it clear that the priority is to serve the patient at the end of the supply chain. The patient takes the ultimate risk with the end product.

Summary

When implementing MES on a new site or existing facility, be clear on the reasons why MES is being implemented. Set a clear vision for the organization.
Ensure everyone in the organization knows why it is being implemented, what the benefits are and how it will be used.

Keep patient safety at the forefront of the implementation. That is the only standard.
Measure the benefits post implementation and how they compare with expectations.
Nothing is final or ever 100%. The best systems will continue to evolve with the needs of the business and the industry.

For further support book an online session with one of our project specialists here

Distractions, Multi-Tasking and Work Overload

Distractions
One of the biggest sources of distraction in the workplace today is technology. Phones, tablets, laptops, messages, emails all have the capability to cause even the smallest disruption. More often than not when running meetings and workshops I have to remind people about these distractions.

There are a couple of basic rules that I insist on everyone following during these sessions.

1. No phones or tablets in the room.
2. No laptops open on the desk unless directly required for presentations or note taking.

You’d be surprised at the look of horror on some faces when I present these rules. There are of course exceptions, someone may be on high alert and be required to be available on the phone. Someone may have a personal issue that requires them to be available. These exceptions are acceptable it manageable. i.e. Have someone outside the room keep watch on these specific phones but the phone doesn’t not need to be in the room.

Devices do have the ability to distract people from what is important. There needs to be a conscious effort from each individual to manage these distractions. By accepting a message or an email when you are in the middle of doing something you are in fact reducing your productivity and focus.

I work on the basis that we can only focus on one task at a time. I have some rules that I follow in order to minimise distractions during work time.

1. Don’t check your email first thing each morning unless there is a specific response or update you are waiting on in order to complete a priority task.
2. By checking email first thing you are inviting others to provide a distraction
3. At the start of your day, complete a task first then read emails. That way if you do get distracted by an email, at least you will have accomplished something first.
4. If you do receive an email that you need to respond to in order to contain a panic, try to speak to the person first. If this is not possible, set up a brief meeting. If neither of these are possible in the short term, don’t respond until you have spoken to the person in question.
5. Unless needed for a specific input or advice avoid bringing a wider audience into the issue. Your colleagues will appreciate it.
6. If you absolutely have to respond to an email that is likely to stir up a response that could escalate then be constructive. Before sending, print off a draft, go to a quiet office and read it aloud. How does it sound?

– At the start of your day, complete a task first then read emails. That way if you do get distracted by an email, at least you will have accomplished something first.

Multi-Tasking
Multi tasking is a myth. In a professional situation is not possible for one person to focus on more than task at a time. That’s about as much as we need to understand about multitasking.

Multi tasking is not to be confused with taking on too much work and feeling overwhelmed.

Work Overload
It is easy to take on too much work at any time and find ourselves slightly overwhelmed with the amount of work we need to do. Early in our careers when we are getting used to how we respond to the professional working situation this can be a frequent occurrence. It was for me anyway and regularly I would take on too much work at the same time.

I would say yes to everything thinking that I would impress people with the amount of work I could do. I had to work late on many occasions thinking that I was doing the right thing but over time I learned that I was feeding the problem. I was feeding the problem and I did not know what the problem was. I thought that I was not working efficiently enough and not working quickly enough. I was wrong – the issue was that I was taking on far too much work without thinking about it.
What I have learned over the years is that you should be able to do your job effectively most of the time by working between 38 to 45 hours per week. (There are always exceptions where we have to work late or on the weekend). If you find yourself in a position where this is happening every day and every week, there is one or both of two problems:

1. The workload is too much for one person

2. You do not have the ability to do the job effectively

In reality, it is rarely the second reason unless there has been some major oversight in hiring you for the position, you have taken on a job that you are just not capable of doing or the scope of the role has changed significantly.

If you do find yourself in the scenario where you have committed too much work, step back and look at these tasks, the priority of these tasks and decide which one of these tasks do we absolutely need to do first.

If you are unable to define a clear priority between these tasks seek the advice of your immediate manager or supervisor and get their input into how you should prioritize the tasks that you have taken on.

Next, provide a plan or outline a schedule that you think is reasonable. Discuss this with your manager or your client. Once you explain the plan honestly and rationally to someone, very few people can argue or complain. In my own experience 99% of people agree. If you do get a negative response – don’t over react negatively or take it personally. The best you can do is inform the person that you will make every effort to get the tasks done in a timely fashion but you still believe that the schedule you have proposed is the most effective way forward.

Summary
Although this article is a mix of three topics, they are related as they can cause disruption and inefficiencies in any organization. Here’s a summary of advice:

1. Distractions – Don’t tolerate them and do not let them disrupt your working day.

2. Multi-Tasking – Don’t go there, it is a myth. If you are trying to do more than one task at a time, both of them will suffer.

3. Workload – think about the tasks you are doing. Prioritize the tasks. Plan your work, then communicate early and often.

If you enjoyed reading this article you can read more here

Please contact us by email at info@systeme.ie

TRAINING

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: info@systeme.ie with some background on your specific issue and we’ll be in touch.

Download our Project Team Motivation Guide Here

TRAINING

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.

Summary

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: info@systeme.ie 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 our 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 a position 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 statements during meetings that have no intention 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.

Response:
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 (and is this a priority)?
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.

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 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 skilful 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: info@systeme.ie with some background on your particular issue and we’ll be in touch.

Download our Project Team Motivation Guide Here