Choose a good balance of knowledge, energy and experience.

I put these three headings together because by themselves they are not very effective. You can have an experienced team without the right energy or knowledge. You can have a knowledgeable team with no experience. Neither of these combinations is very effective. If you can select on your team a strong blend of experience, knowledge and energy, this can be a very effective combination.

Knowledgeable people that have the relevant project experience and the energy to deliver project tasks can be powerful. If you get the knowledge, experience, energy balance right on a project team, anything is possible, and progress will be sustained.

One fact that everyone on the team needs to understand is that no one person is bigger than the project or the team, no matter how good they are or how good they think they are. No one is indispensable.

Clear roles and responsibilities

Another essential element of a high performing project team is that they all understand their roles and responsibilities. This is particularly important on long term projects. The boundary of responsibility and the role may change but once they are clear, the team can work together effectively. It can of course be possible to have a primary responsibility and a supporting role in a project, this can be clearly described in the project RASCI Matrix, RASCI – Responsible, Accountable, Supporting, Consulted, Informed) a vital document for all projects that needs to maintained and updated regularly throughout the life of a project.

If you get the knowledge, experience, energy balance right on a project team, anything is possible, and progress will be sustained.

Unified focus

The ability for project teams to have the same focus or priority is a key attribute that is often overlooked. Once the project priorities are clear for the entire team, much unnecessary communication and “non-value add” meetings and discussions can be avoided. Many project meetings take place to “clarify” the priority for the team and stakeholders. If the priority or priorities are clear from the beginning, then the team can focus their efforts on the work.

It is not uncommon when faced with several tasks that someone will need clarification on what should come first. The project plan should spell this out and should leave no room for discussion. This can be helped with the addition of a Kanban that can serve to remind the team of what is coming next and also to indicate the new priority or order of execution should it be changed for any reason.

Transparency

If there was one quality to start with when training new project managers it’s the importance of transparency. In large organizations, politics, pressure, personalities and context can all make it difficult to be transparent on a project. If there is transparency at all levels of the project it can have a number of advantages such as:

1. Dealing with problems and issues – the more you know, the sooner, the quicker any issues will be resolved.
2. If transparency is encouraged then potential issues can be avoided by discussing the waring signals
3. Transparency will encourage accurate record keeping which is particularly important during testing, where test failures and challenges need to be documented accurately.
4. Encouraging people to put their hand up and ask for help with out fear or hesitation.

Evaluating team performance

When evaluating how a team is performing, we need to look at a number of factors:

Completion of work in a timely manner – are deadlines being met consistently?

What is the quality of the output? Is there any repeat work involved due to poor quality?

How are the team working together, supporting each other and communicating?

How to they perform under pressure? Do you need to “ask” people to stay late to complete a deadline or is it done regardless?

How many of the same issues are recurring? Are the team learning from previous errors?

Effective leaders will always deal with any concerns at the earliest sign of a pattern emerging.

Managing high performing teams

When managing a high performing team, it can be a challenge to bring them down to earth sometimes. High levels of confidence can be very powerful but if not managed correctly they can lead to complacency. High performing teams do the basics right every time, if you keep focus on maintaining a high standard on basic tasks, these can be the building blocks of success.

Utilizing a sports analogy, many of the world’s most successful sports people when asked about their success have alluded to the fact that they do they focus on being brilliant at the basic skills of their sport. Soccer for example – passing, running and shooting – that’s what wins games. Ensure the basics are done well and never let the team forget that.

Pairing people with the right partner is a huge factor here too, matching personalities and skills so team members can learn and challenge each other can enhance your team’s output and serve to ground them in the benefits of teamwork. I’ve never subscribed to the concept of autonomous self-managing teams but partnering and mentoring internally can bring with it a high level of internal team management to maintain performance.

Giving the right feedback at the right time is another element of managing high performing teams. A former boss of mine would often say “That was fantastic – well done. Now what did we learn this this project and how can we improve on the next one.” That sounds better than “You’re good but you do better.”

In summary

1. Choose a good mix of knowledge, experience and energy
2. Ensure that everyone is clear on their role and responsibilities
3. The team must have a unified focus or the same priority
4. Encourage transparency in all areas of the project
5. Look at several factors of teamwork when evaluating overall performance, not just volume of output.
6. Manage and control performance by focusing on maintain a very high standard on the basic skills and tasks.

The post Managing high performing project teams appeared first on System E.

Can I trust my team to work remotely?

I’ve been managing projects remotely for several years now. The hardest part is starting. A question that I often get asked is – “how can I be sure that they will work just as well at home and how can they be trusted?”

A simple response to this is to remember why you hired the person. You hired them for their skills, experience and professionalism, so if you can’t trust a person to work effectively at home or remotely, then why would you hire them in the first place?

Talk to the team before the decision is made, let them know that the project depends on them behaving professionally and doing the same work in the same time. As remote working will become normalized over the next few years, companies need to prepare for more work done from home.

Working hours

The one aspect of remote working that is always impacted is working hours. Some people prefer to start early, some prefer to start late. You should be reasonable with this one as your flexibility will be paid back in spades. Be firm around meeting times but not rigid. If there are specific meetings that need to happen, get a consensus from the team on what the best time is to hold specific meetings.

Once the time has been agreed it must be respected, avoid loose time arrangements around the daily meeting. This is the one opportunity for team contact each day and it is important that this is respected unless there is a valid reason.

The one risk here is that a personal situation at team members home may begin to infringe on the work, meetings and overall delivery. If you suspect there is an issue or a chronic problem, address it head-on. Avoid letting it fester.

After a few weeks, you know who is being effective in working remotely and who is not. Again you must deal with any performance issues as you would if they were occurring in an office situation.

so if you can’t trust a person to work effectively at home or remotely, then why would you hire them in the first place?

Time focus v task focus

When managing any project, it is always better to focus on tasks and deadlines as opposed to working hours. If you transition the project team from working together in an office to remote working, this becomes more important.

A good approach is to set the deadlines for each week. “What do we need to complete this week to keep the project on track?” Some team members will not need much management, some will – the same as they would in an office. Your responsibility as a project manager is to ensure you remove all the barriers to progress and ensure you get the desired results within the specified timeframe.

This is best achieved by not measuring performance by the hours worked but by what has been delivered within a specific time. Once the deadlines are met, the number of hours worked is somewhat secondary. Once people get into the habit of this approach, it can reap a myriad of benefits for the project and the team member.

What tools should we use?

The simple answer is to use whatever works. There will be tools needed for communication, online meetings, video conferencing etc. These are simple enough to use, however not everyone knows how to use them. Before the team is dispersed from the office, ensure that everyone knows how to use the communication tools. The last thing you need is the first 10 minutes of each call occupied with “Hello”, “Can you hear me?”, “Are you there?” etc,……….

Each time member should sign a training form indicating that they are now trained in using the tool both at home and at work.

One big aspect of online meetings is being able to see each other. Initially, it can be a little odd for people that are not used to seeing themselves on camera. Once we get over this initial discomfort, the camera will be your biggest game-changer in keeping the team connected. There are a few advantages using the camera during video calls and online meetings.

1. You can see facial expressions and body language
2. People will make an effort to tidy up the surroundings to facilitate work
3. People will clean up and dress accordingly for the call, you do not need someone dialling in from the bed or the bathroom (trust me it will happen!!!!)
4. It helps build relationships

The next tool that is necessary is a tool for communicating the plan, setting tasks, monitoring progress and raising issues. This can be as simple as a spreadsheet or Kanban style app. If you are used to working with a stand-up meeting with a whiteboard and post-it labels, then this information needs to be transferred to a digital alternative.

Before the team is dispersed take plenty of photographs and assign one of the team the task of transcribing the whiteboard, post-its, or scrum board into a digital format. Focus on the content here and the effectiveness of the information. Do not worry too much about the aesthetics, these can be improved with time.

An application or spreadsheet should be utilised for managing tasks. Individuals can manage their own tasks in whatever way they see fit but there needs to be a central tasks management log for assigning, monitoring and managing project-related tasks.

Running project meetings with a dispersed team

Communication is key when running a project. When running a project with a remote team, this is even more critical. You need to ensure that everyone is on time, as lateness for meeting times can develop into a disruptive habit.

Develop a routine for the meeting just as you would with a face to face project meeting. Run through the usual topics – Overall status, work completed since the last meeting, plans for the next day and discuss any risks, issues or stumbling blocks.

The team need to maintain a tactile relationship with the project and for this reason, it is imperative that each team member provides an update for each session. Knowing that they need to provide an update will ensure that they prepare for the meeting. A few minutes of preparation for any meeting can make all the difference.

In summary

1. Trust the team. If they are good enough to work in the office, they can be trusted to work at home unsupervised.
2. Be reasonably firm with the working hours but not rigid. Maintain the same meeting times.
3. Focus on the tasks completed each day/week and the overall progress made more so than the number of hours worked. Performance management is all about measuring results and not hours.
4. Insist on the use of web cameras at the meeting, it is very important to maintain the human connection, particularly on a long term project.
5. Convert all whiteboard, post-it, scrum boards to a digital medium, quality of content is key here, not colours.
6. Run the project meeting as you would run a face to face meeting. Ensure everyone gives an update.

Visit our online store for useful products and our downloads page for free resources.

More articles like this can be found here

The post Managing remote project teams appeared first on System E.

Nobody wants to talk about the boring stuff

How many articles, news reports and stories have you read about how a large software project was supposed to cost X and take XX months only to find it needed double the amount of money and double the time to complete? When the project finally was complete the system did not function as expected and created more business issues than it was meant to solve.

There is a burning desire in all of us to implement a shiny new software system and set of user interfaces that look great and make us feel that we are doing a great job. If however you talk to any users of a large complex software system and they will provide you with a list of problems and inefficiencies and statements like “we weren’t involved at the start of this project” or “ I told them at the time that this was not going to work”.

The fact is that there is a lack of enthusiasm about discussing the mundane (but sometimes critical) elements of the business but this is where most large software projects begin to fail or begin to succeed. The time needs to be spent in discussing and mapping the ordinary mundane functions. The best time to do this is at the beginning of a project. A strong business analyst will carry the project team through a series of workshops to extract all these details.

The devil really is on the detail

When a company decides to embark on a large software project this is generally driven out of a strong influence such as digital transformation and or the need to remove paper records from the main business processing functions of a company.

This is more difficult than it sounds. Consider one Standard Operating Procedure (SOP) within an organization. This is used to describe how a section of the business process is performed. The SOP may refer to many paper forms that need to be completed as part of the process. The SOP may also refer to other SOPs – upstream and downstream,

So when we think of a single SOP we have to consider everything the SOP touches within the organization. The full extent of this scope of work can only be defined by detailed business process mapping. This is where every element of the business is mapped by all departments in the business.

The urge to get a solution built can often lead to this exercise being curtailed. The knock-on effects of this decision are often not felt until the solution testing phase. So, the process must be mapped to a granular level of detail, only then can the full extent of the work be understood.

Too much focus on the technical features of a new system can lead to a loss in focus on the function it serves and the reason why it needs to be implemented in the first instance.

Managing user and stakeholder expectations

It is a standing joke that many large software system users won’t know exactly what they need or want until they see it. There is an underlying element of truth in that statement.
The trick is to create a reasonable prototype as soon as you can. If you ask a good project manager and a software developer to define a prototype, you will get two completely different answers.

The software developer will insist on having a full set of server architecture, licenses, databases before they can create a prototype.

A project manager (or business analyst) will choose a quicker route to prototyping, i.e. use a selection of screenshots in a presentation to mimic functional software.

If we pitch one against the other, we are not comparing the same thing so we must ask what we are trying to achieve with the prototype?

– Too much focus on the technical features of a new system can lead to a loss in focus on the function it serves.

Answer to give the user a better idea of what the solution will look like to make it easier for them to visualize the end-product. The project manager’s solution will do the job for a fraction of the cost and time effort. At an appropriate time in the project, full working prototypes will be available but until then it is critical to keep moving and give the user something to make them think.

Is corporate culture causing projects to fail?

In many organizations, these large projects for business transformation are launched with the usual corporate spin and fanfare that one would expect when millions (or dollars or euros) are invested.

“Go live” dates sometimes driven by business goals or legislation are decided upon without understanding this detail. These dates are then set in stone and driven done to the various project managers and project team members from company leadership.
When the project teams dive into the detail and see that the scope of work is just not possible to deliver within the allocated timeframe. The project is then doomed to failure from the beginning and this has quite a negative effect on the individuals involved. The company leadership get frustrated at missing milestones and yet another large software project gets a bad reputation.

This is where the project team need to get organized and present the strategic case to the business leaders as to why the expectations for the project are not realistic.

This is where the project manager can influence the stakeholders and company leadership and save the project.

What can we do about this common scenario?

1. Rather than committing to a date that can’t be achieved, define what exactly can be achieved by that date.
2. Chart a roadmap (based on facts and solid input) on a roadmap to deliver the full original intended scope of work.
3. Keep the “go live” date albeit with limited functionality.
4. Sell the benefits of going live with limited functions as a better opportunity of the organization to transition to the new ways of working and to test the system in the live environment while minimizing the impact to the business (not exposing all business operations to the new system).
5. If the plan is realistic, based on fact, and risk assessed appropriately, it will be difficult for stakeholders to refuse the new approach.

I have yet to see even the most unreasonable autocratic organizations refuse a well thought out plan that is based on good metrics by an experienced team. The client stakeholders may not be entirely happy with the situation, but they cannot argue with the facts.

Start your revised plan off on the road to success
Once you have committed to the re-planned work, you need to deliver on it. It is very important to orchestrate the work so that one significant milestone is met very soon after the plan is launched.

This will serve 2 purposes.

1. Demonstrates to the stakeholders that you can deliver on a plan
2. Give the project team confidence that they can deliver on a plan.

https://systeme.ie/project-managers-need-to-be-leaders-not-administrators/

Read more here

Communication

Communication is key when managing a re-planned project. There may be an enhanced level of scrutiny while the project team rescues their reputation. Embrace this as the only way to manage excessive scrutiny is to over-communicate. You will soon be told to reduce the frequency of communication. Ensure that each stakeholder has an update at least on a weekly basis with a more detailed update on a monthly basis.

https://systeme.ie/essential-traits-project-manager/

Read more here.

In summary

1. Resist the urge and the pressure to dive straight into the software/technology fix before the requirements are fully understood.
2. Get smarter about producing prototype functions, you don’t need a full set of server architecture and licences to make a prototype – basic animation will do.
3. People, not jargon nor templates will get the project done – spend time choosing the best people
4. Communicate, communicate, communicate – keep everyone informed of everything as frequently as you can
5. Focus on the benefits of technology, not just technology.

https://systeme.ie/controlling-project-scope/

Read more here.

The post Why large software projects fail appeared first on System E.

As with any body of work, project managers need to learn from every experience, good or bad. When issues occur on projects people are often puzzled at how they happened in the first place. There are a few occupational hazards that come with the territory of being a project manager. If you don’t get the basics right, you will have issues might have issues.

In many ways, it’s like an electrician not taking the correct safety precaution and getting an electric shock and wondering why. In many organizations today there is an over-reliance on procedures and templates, and this is some way is contributing to experienced project managers reducing reliance on their own knowledge and experiences. In this article, we discuss some common problems and how to anticipate and even prevent them from disrupting your project.

Roles and responsibilities

At the risk of sounding like a statement from Project Management 101, this is a recurring issue that we are seeing constantly. At project initiation as responsibilities matrix is (or should be) drawn up. This should be as high level or as detailed as it needs to be. Every line item on the project plan needs to have an owner and may need a supporting cast in order to complete the task. The RASCI (Responsible, Accountable, Supportive, Consulted and Informed) matrix is a key document here. It is however generally underutilized. It is normally completed at the beginning of a project and not touched again. On a long-term project, anything can change, and therefore the roles may need to change to adapt and ensure the same level of ownership.

At the first sign, that people are unsure about their role on the project, e.g. someone may state “I wasn’t aware that this was my responsibility.” – Stand everyone down, get into a room and review the RASCI against the subject matter. Something new may have been introduced to the project so you need to update the RASCI based on the newly acquired knowledge and ensure everyone is aligned and clear on the content. If anyone else makes that same statement at any stage during the project, repeat the process.

If you let these types of issues fester. They will lead to one or more items being left undone or neglected to the point it causes a delay or a bigger issue down the line.

Change of personnel

We plan and execute projects with the knowledge we have at a point in time. If we have new information, we may need to re-plan, do things differently and re-think the project. Projects are not immune to personnel changes, people move jobs all the time, people become ill, people take holidays, people have unexpected long term absences from work. So, we need to build this in at the start.

Some roles may be more important on a project than others, i.e. if they leave during the project the impact will be bigger and more sustained. In large organizations, priorities change all the time and it is not unknown that people can be re-assigned to other projects or other work.

So, again we use the basic foundations of all projects – the RAID log. (Risks, Assumptions, Issues, Decisions), and the RASCI as mentioned above. As a brief example, we place risk in the log under “Resources” that if the Business analyst is removed from the project, there will be a negative impact, time or budget. We accept and agree on this as a medium risk. We also need to asses the risk regularly. We could also log this as an assumption at the beginning that all personnel will remain on the team. If the Business Analyst is moved or seconded to other work, then you need to re-assess the risk and move it to the issues log.

Before this happens, you need to make the impact clear to the decision-makers. The RAID log is the perfect vehicle for this, and if it has been captured accurately, then the decision-makers will accept they understand the impact of moving the person to another role outside the project. We may then need to record the decision in the Decision section of the RAID log. This will avoid any blame or unnecessary attention on the project team later. The decision log will be clear on who made the decision and why therefore no surprises. This practice is particularly helpful in organizations that are prone to outbreaks of project amnesia from time to time.

There will always be unexpected personnel changes that you can’t see coming. To minimize the negative impact of these issues, you must ensure that all project documentation and material is accessible, clearly indexed and shared with the entire project team. There may also be a need to review the RASCI temporarily until a suitable replacement can be found.

Making sure there are no key documents stored on local hard drives, personal spreadsheets is key here. Insist upon and check regularly that shared network drives and folders are used, task management apps and plans are updated regularly and not stored locally.

Missing deadlines

Probably the biggest pet hate of most project managers, deadlines can be missed when they are missed, you need to get the bottom of it fast. You also need to have a strong culture of communication to give an early warning. During initial planning, you must look at all possibilities in how you can best achieve your targets. As the project manager, you have an obligation to maintain focus on the end goals and be relentless in the removal of actual or potential obstacles that could get in the way.

During planning, you paved the steps to necessary to reach each milestone. If any of those steps are delayed, the chances are that the milestone to which this step is contributing will be delayed.

The advice here is simple, if you miss a small deadline, you have a couple of options – re-plan and push the main milestone out or regroup and try to recover.

You can read more about this in the following blog:

https://systeme.ie/project-managers-need-to-be-leaders-not-administrators/

Scope Creep

The simple advice here is you need to make it difficult for people to change the scope of work and create scope creep. If you make it too easy for people to at work to your project while not reviewing the impact of this extra scope, they will keep on piling it on until it becomes unsustainable.

If someone requests something extra that is outside of the original scope you need to make them work for it. The extra scope will impact cost, schedule and complexity. So, utilize the project change process. Ask the requester to book some time with your best business analyst to gather their requirements. Make a detailed assessment and then get back to the requester with the impact in simple metrics of cost and time etc. If a decision is made to proceed, then the project change control process must be followed to approve the change before adopting it into your scope of work. You can then re-plan. For more reading on controlling scope creep, see this previous article:

https://systeme.ie/controlling-project-scope/

Communication

Communication is key to the success of any project. This is how you find out about any potential issues in advance of them becoming a big problem. Communicate often and in small bursts. Maintain team meetings weekly, talk 1:1 with team members at every opportunity. Look out for any signs of friction between the team and deal with them promptly. Ensure that all team members know that they can call you at any stage for a chat to discuss anything that may have an impact on the project.

Communicate clearly and ask for feedback. Utilize the multiple forums and tools at your disposal and make it easy for people to give feedback and make suggestions. When running project meetings and status updates, read between the lines to understand what is really going on outside of the official conversations.

This article provides more information on this topic:

https://systeme.ie/essential-traits-project-manager/

In summary

What we’re saying here is that most project problems when examined could have been prevented or have had their impact reduced by following many of the basic foundations of project management. You cannot prevent every problem, but you can learn from previous experiences and certainly reduce the repetitions of previous problems.

The post Project problems – prevention and anticipation appeared first on System E.

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 due to the efforts of the project manager, 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 of 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 raise 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 alone – effort (and resulting output), and interdependencies are 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: projects@systeme.ie we’d love to hear from you.

The post Project Managers need to be leaders not administrators appeared first on System E.

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 has 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 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 a 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 plans 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 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 different 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 the 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 the 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 is 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 different 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: projects@systeme.ie we’d love to hear from you.

The post PM Terminology and Methodology appeared first on System E.

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

The post Projects and Dark Matter appeared first on System E.

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.

The post Creating Positive Habits for Project Delivery appeared first on System E.

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

The post Managing Small Project Teams appeared first on System E.

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

The post MES Systems and Benefits appeared first on System E.