Category Archives: Methodology

What is Little Data? And Why Do Project Managers Need It?

One of the fastest-growing technology trends today is Big Data, probably behind Internet of Things and ahead of Virtual Reality. For instance, a search on the job site Indeed for “Big Data” returned almost 20,000 entries.

But what about Little Data (which only gets four hits on Indeed)?

Big data is mining huge, heterogeneous data sets and pulling out subtle information that can inform all sorts of decisions.

Let’s look at climate change science as an example. Data comes from atmospheric measurements over Hawaii, temperature data across the globe, ice cores from Antarctica and Greenland, underwater measurements from all the world’s seas, and more. Some of the data were taken by satellite last week; others written in notebooks centuries ago.

[Further Reading: How to Be a Project Team of the Future: Preparing for Industry 4.0]

It’s been pored over by scientists from every country in the world. The data and analysis needed to predict how the climate is changing and will change is complicated. To really understand it requires a PhD. The details are so complex that we have been unable to decisively act on this critical issue.

What Is Little Data?

Little data is the opposite. It’s the 2+2=4 kind of things.

Little data is the obvious observations and conclusions that those paying attention will catch and can use to their advantage. It’s looking outside, seeing it’s raining, and deciding to put on a jacket. It’s noticing that the prices and quality of the food is better at one store than another and using that information to decide where to shop. It’s noticing that if you drink coffee after 5 p.m., you have trouble going to sleep, so you stop drinking coffee after 5 p.m.

Little data has three steps:

  1. Gather data.
  2. Do some straightforward analysis of the data.
  3. Act based on your analysis.

To some extent, little data and big data are close to the same thing, it’s just a matter of degree. The biggest difference is that the analysis for little data is straightforward. If you’re looking for someone with a PhD in math to help with your analysis, that’s not little data. For little data, you should be able to do the analysis in Excel. The challenge is knowing how to respond to your results.

Improve Schedules with Little Data

Here’s a straightforward way to use little data to improve your schedules: record task estimates and actuals. The data should include who did the estimation and the work. Using a pivot table in Excel, you can see which estimators typically underestimate or overestimate. You can also see which of your team members take more or less time than was predicated. There are many ways this data can improve your organization, including:

  • Decrease the bias of future estimations
  • Identify team members who are not using best practices (and therefore take longer)
  • Identify team members who have practices you should transfer to other team members

As is often the case, data acquisition is straightforward, analysis simple, and the response requires further digging.

Measuring KPIs

Key Performance Indicators (KPIs) are a common little data management technique. Leadership decides that certain easily measurable metrics are key to the organization’s success, targets are set, and data acquired. If the performance does not reach the target, then some form of response is taken.

For example, you may be managing a manufacturing line. Your KPI is the number of units manufactured per hour. In creating the manufacturing process, you know you can build 100 units an hour, so you set your target at 80 units an hour to account for the normal hiccups (e.g. you’re training a new team member).

[Further Reading: AI, IoT, and the Future of Manufacturing]

Data collection and analysis are easy. If you’re meeting your target, you can move on to other issues or raise the target. Ideally, if you don’t meet your target, the response is agreed to prior to acquiring the data. Often it just indicates you need to dig deeper, as in this case. As is all small data analysis, the challenge is in the response, not acquiring or analyzing the data.

A Real-Life Example: Test Scores

One of the most controversial examples of little data are standardized school tests. The data is homogenous and straightforward (if time consuming) to collect. The naïve analysis is trivial (average score by grade and school). The response is complex and fraught with challenges.

In 2010, an elementary school near my house was labeled as failing according to the No Child Left Behind law. A majority of the students were from refugee and immigrant families. Many didn’t speak English at home, which certainly posed a challenge for the school.

The metric, test scores, didn’t determine what action was called for, but made clear there was a problem. The district responded by bringing in a new principal and new teachers, and a concerted effort was undertaken to improve performance.  After four years, the performance of the school went from one of the worst schools in the state to only a bit worse than the average school. The little data approach showed that by the metrics we use, the interventions improved the performance.

But this same metric can be misused. There are two middle schools near our house, and we choose to send our son to the one with lower test scores. The school our son goes to is incredibly diverse (including most of the kids who went to the formerly failing elementary school), with a great vibe and dedicated teachers. Test scores can tell you when a school is broken, but it’s not useful in comparing two functional schools. How a school fosters creativity, teamwork, and curiosity are not captured in any test.

This same data can also be used in a big data analysis. Throw in demographic data from the census, housing prices from the country, income data from the IRS, alcohol and cannabis consumption data from Washington State and some subtle correlations that aren’t immediately apparent might appear.

Of course, they might just be random chance; that’s why you need to be careful with big data in a way that you don’t with little data. If your school has the lowest test scores in the state, you know you have a problem. If there’s a weak positive correlation between playing sports and grades, that doesn’t mean every child needs to immediately join a league.

It can be hard to rally the troops to fix a broken team or process. When you come in with data showing how far you are from where you’re supposed to be, it’s much easier to drive changes.  That’s true whether it’s replacing a principal or fixing a broken manufacturing process.

Use Data Thoughtfully

Throughout your day, you’re inundated with data. The key to both little data and big data is to thoughtfully filter out what is unimportant and turn what is important into knowledge, which is data with context and meaning. Then you use that knowledge to inform your actions. If the data can’t lead to action, it’s worthless. An extreme example of this is Sherlock Holmes’s lack of interest in the fact that the Earth orbits the sun,

“What the deuce is it to me?” he interrupted impatiently: “you say that we go round the sun. If we went round the moon it would not make a pennyworth of difference to me or to my work.”

Though, as a former astronomer, I don’t encourage following Holmes’s example, it is important to focus our efforts on data, big or small, that help us make better decisions.

 

Ready for a new project management tool, but still need to get your boss’s buy-in? Learn how to build a compelling business case with this in-depth guide. 

6 Top Project Management Books for Engineers and Manufacturers

While engineers learn a lot of valuable skills in school, project management isn’t always one of them. Many engineers end up learning PM skills on the job and on their own time.

If you’re an engineer looking to grow your project management skillset, you’re in the right place. To compile this list, we dug through Amazon listings, forums, blogs, and review websites to identify the best project management books specifically for those in the manufacturing and engineering industries.

[Further Reading: 5 Reasons Engineers Need to Learn Project Management Skills]

Critical Chain by Dr. Eliyahu M. Goldratt

Who said business books have to be a bore? Dr. Eliyahu M. Goldratt turned the traditional how-to book on its head with this “business novel.” Goldratt explore his Theory of Constraints (TOC) through the story’s main character, a university professor who has just returned from a large corporation that uses TOC. Over the course of the book, Goldratt walks readers through the five principle steps of TOC. This is an excellent overview of TOC packaged in a novel full of character development, conflict, and the occasional dramatic scene.

Epiphanized: A Novel on Unifying Theory of Constraints, Lean, and Six Sigma by Bob Sproull and Bruce Nelson

Management consultants Bob Sproull and Bruce Nelson borrow from Goldratt’s storytelling concept to explore the advantages of using Theory of Constraints, Lean, and Six Sigma together. This book tells the story of two consultants who turn around an ailing company by implementing a unification of the three methodologies.

In the appendix, the authors offer a closer look at how the methodologies described in the novel can be applied to your own organization and why a combination of the three creates the best results.

Project Management for the Unofficial Project Manager by Kory Kogon, Suzette Blakemore, and James Wood

In today’s workplace, most employees are expected to competently run and manage projects. The trouble is, many haven’t been formally trained.

This book offers practical, jargon-free advice for the accidental project manager. The authors use real-world examples of project successes and failures to illustrate the most important steps and practices for effective people and project management.

Industrial Megaprojects by Edward W. Merrow

When large-scale engineering and construction projects—think off-shore oil platforms, chemical plants, dams—go wrong, they go horribly wrong. In “Industrial Megaprojects,” Edward W. Merrow uses humor, conversational language, and 30 years of experience to explore why large-scale projects fail and what can be done to prevent this. While this book focuses on megaprojects, many of the insights can be applied to engineering and manufacturing projects of any size.

Project Management Case Studies by Harold Kerzner

If you enjoy learning from others’ mistakes and successes, this one’s for you. Project management guru Harold Kerzner dives into more than 100 case studies drawn from real companies to show what worked, what failed, and what could have been done differently. The book covers a wide array of industries, including medical and pharmaceutical, aerospace, manufacturing, and more.

Project Management for Engineering and Construction by Garold D. Oberlender

This book presents the principles and techniques for managing engineering and construction projects from the initial concerting phase, through design and construction, to completion. What sets it apart from other PM books is the focus on applying PM techniques and principles to the beginning stages of a project to influence the budget, scope, and timeline as early as possible. While other books dive right into the construction phase, Oberlender offers a solid argument for applying PM principles earlier in the process.

Bonus: LiquidPlanner Project Management Resources

How to Manage Chaos: Advice on Project Management and Workplace Conundrums

Every month, project management expert Elizabeth Harrin fields readers’ questions about the challenges, risks, and rewards of project work on the LiquidPlanner blog.

We’ve compiled our favorite columns in this eBook. Over 30 pages, you’ll get Elizabeth’s take on a range of project management and workplace topics, including:

  • Ways to get more resources for your project.
  • Strategies for juggling multiple project tasks
  • How to manage a micromanager

Solving the Top 9 Project Management Challenges

This eBook provides practical tips and solutions to nine common project management challenges. You’ll also see how LiquidPlanner helps you meet your challenges—and turn them into opportunities.

The LiquidPlanner Blog

Every week, we publish guest posts from active project managers.

When You’re the Company’s First Project Manager

In the beginning, project management was formless and empty, and darkness was over the work breakdown structure. The Founders looked over the face of the startup and said all is good. And there was evening, and there was morning—the first day (metaphorically).

Then the company grew and its teams were fruitful and multiplied.

Projects competed for resources, and everything was late. The Founders looked upon the chaos and were not pleased. They looked upon the multitudes and chose one who was more organized or less busy than the others and said, “It is up to you to be a prophet, bringing order to the chaos and leading the projects to the promised land of on-time delivery within budget. You must quiet the babel of squabbling the offends our ears.”

So you have now been appointed to be your company’s first project manager.

You may have never been a project manager. You may have never worked with a project manager. Your company has no templates, no resources, no software, and, most importantly, no culture of project management.

Where do you start?

Have a clear mandate from the leadership.

I once worked at a small company without project management and was struggling because of that, so I just started doing project management without any training or buy-in from the company leadership.

This did not go well!

I wrote the company’s first requirements document. As we reviewed the document, one of the stakeholders said, “I’m used to just complaining when engineering delivered something that isn’t what the market wants.”

I explained it was easier to build things right in the first place, which made a lot of sense to him. Having a requirements document reduced the constant churn of the product definition and helped the engineers focus on what they should be delivering.

Delivery dates were based on when someone wanted a product and not a detailed plan. I was sick one day, and on my return the scope of a project I was leading had changed significantly, but leadership expected no schedule slip nor did they allocate additional resources. When delivery dates aren’t based on real plans, then management can’t make the cost-benefit trade-offs that they should.

People were moved on and off projects with no warning or notification. No one set priorities among the large number of active projects. Not surprisingly, every project was late.

Without a mandate from the top, I was unable to control how resources were allocated or expected completion dates were set. I could change things around the margins, but not fix the underlying . Quoting from Reinhold Niebuhr’s Serenity Prayer:

God grant me the serenity
to accept the things I cannot change;
courage to change the things I can;
and wisdom to know the difference.

Do what you can, make the case to do what you should, but if there’s no buy in, accept that and hope that your example of good management over time will change things.

Always be adding value.

For a salesman, the key is to Always Be Closing. For a project manager, you need to always be adding value, or at least not subtracting value.

Before you were anointed as your company’s first PM, things were done a certain way and it probably gave the individual contributors a lot of autonomy. They probably “knew” what needed to be done (and were probably right most of the time). They won’t appreciate you coming in, setting priorities, and “getting in the way”.

For you to do your work (e.g. building schedules and writing status reports), they’ll need to spend time sharing their expertise and knowledge. If they don’t see the value project management adds, they’ll see this as “wasting” their time that should be spent doing valuable work.

You need to be gentle but firm with this pushback. Make sure you get what you need to be successful, but be as accommodating as possible. Maybe you put together a starting point work breakdown structure and ask, “Where is this wrong?”

Listen more than you speak. Before sending a status report to stakeholders, send it to the team. This provides the team with an opportunity to check it for accuracy, helps them understand why you’re asking for their updates, and shows them that their concerns are being communicated up the chain.

Whenever possible, be a resource to make their job easier. One of the best ways to help the contributors is to create schedules based on input and logic, rather than management’s hopes and dreams. Having clear requirements can be a great help to the individual contributors as can going to battle getting resources (e.g. software upgrades, test equipment).

You could volunteer to take on vendor logistics and management. Everyone should know that you want to help and nothing is beneath you. Be careful not to take on tasks that the team doesn’t want you to do.

Methodically build your infrastructure.

You’re starting with a blank slate, which is a wonderful opportunity and a daunting task. You’ll need a task management tool (like LiquidPlanner), bug tracking system, standard-operating procedures, document control, and the list goes on and on and on.

Where to start?

Pick the biggest project management related problem you currently suffer from, and work on solving that. Maybe managing resource conflicts is the biggest problem, in which case I’d start with a list of every project in priority order, which can help manage conflicts.

If that doesn’t solve the problem, try creating a matrix with every project on one axis and all resources on the other. Add how much time each team member is expected to spend on that project over the next two weeks, and work with the managers to update this sheet regularly. If any person is loaded by over 85 percent, gather the impacted managers and negotiate.

If that doesn’t solve the problem, then implement a tool like LiquidPlanner that can balance resources automatically across multiple projects. In every case, implement the simplest solution that solves the problem.

Be a problem solver.

As you help your company eliminate barriers to success, the team will see the value you’re adding and be more eager to help you build strong plans.

When they see delivery dates based on detailed schedules they helped create rather than when somebody wants something delivered, they’ll be happy to contribute to the planning processes.  When engineers no longer feel pulled in five directions by three people, they’ll understand why you’re not just “overhead”.

Every time you solve a problem it makes the next one easier.

Agile Team Transitions Are Not Always Textbook

Project teams transitioning to Agile can often struggle with project roles and the overall team structure. Transitioning to an Agile team is a change in mindset, team organization, and the team’s culture.

Common questions include:

  • Where does the project manager fit into the team?
  • Isn’t the Scrum Master the project manager?
  • Who sets the priorities for the software developers?
  • Who gathers the requirements?
  • How does Agile “really work” in an enterprise organization with global teams?

To understand how Agile teams are different, it is helpful to understand how traditional teams are organized.

Traditional Team Organization

The traditional software development team is comprised of the following roles:

Role Responsibility
Business Customer / Client Provide the business process knowledge and requirements subject matter expert
Project manager Manages the project management processes to successfully deliver the project – initiation, planning, execution, monitor, control and close
Technical lead Leads the technical solution delivery and directs software development team
Application architect Designs the application architecture based on the company’s standards, computer infrastructure and network environment
Business analyst Gathers requirements from the business customer
Systems analyst Translates business requirements into specific system requirements for software development
Developers Design, code, and unit test the software solution
Test lead and test analysts Coordinate testing efforts and verify the software solution meets the business requirements
Infrastructure lead Coordinates the infrastructure and server setup
Database Administrator Creates and maintains the database

All of these resources typically come from different resource pools. Delays are introduced as each resource completes their unit of work and submits request to the next team member to complete additional work. If you’ve ever had to introduce new architecture, stand up a server in an enterprise data center, or modify a development, QA or production database, then you’re very familiar with the constraints in this model.

Agile Team Organization

If you pick up a book on Agile or Scrum, you’ll often read about the best teams are self-organizing, cross-functional, and self-directed. The Scrum Guide only defines the three main roles in Scrum: the product owner, the scrum master, and the development team.

Role Responsibility
Product Owner The single person accountable to the product and responsible to ensure the requirements in the product backlog are clearly defined, prioritized, and communicated to the team
Scrum Master Facilitates the Scrum practices, supports the product owner in managing the product backlog activities, coaches the development team,
Development Team The group who does the work to deliver the product

Teams transitioning to an Agile model will wonder what happens to the analysts, the technical lead, the project manager and other traditional roles. Depending on the Agile maturity in the organization, these roles will still exist within the team.

Remember the development team is the group that delivers the product and that can still include a project manager, a test lead or business analysts.

Many organizations talk about being Agile but don’t always have a dedicated product owner who fulfills the role of the product owner. In this case, the team needs to supplement with an empowered business analyst. The project team may not have implemented test automation or test-driven development, so traditional test lead roles will exist.

One of the concepts with mature Agile teams is the team members are cross-functional. This means the skills for business analysis, systems analysis, database development, test automation, and project management exist within the team instead of having separate roles for separate people.

Think about the last high performing team you worked with. The individuals likely shared all these skills instead of relying on separate individuals. My strongest performing team still had a project manager, but that same resource understood business and system analysis as well as testing best practices. The development team also understood the business context and had database development skills.

Conversely, my worst performing team had these skills separated across individual roles. To make a database change in the development environment, a ticket had to be submitted to the DBA team, then escalated because the team wasn’t responding in time. Separate testing resources were allocated for a fixed period of time and often couldn’t test in a timely manner. Consequently, velocity suffered and the team motivation declined.

Not very Agile huh?

Improving with each sprint

Building a team that is cross-functional, self-organizing, and self-directed is an evolution in Agile maturity. The teams I coach today still struggle with reaching this state as many organizations have the silos that prevent teams from working efficiently. Other teams simply struggle with the change from top-down direction to a team centric approach. The good news is adopting Agile practices provides the feedback loops for the team to improve.

During a product backlog grooming session, one of my teams was hesitant to provide individual story point estimates. Team members would look to the team lead for approval because previously the team lead would direct the work. It took a few sprints but eventually the team became comfortable with the new processes. That team is still progressing by adopting different Agile techniques, but they are improving with each sprint.

Transitioning isn’t textbook

If you are implementing Agile practices in your organization, you likely recognize it isn’t a textbook transition. Self-directed, cross-functional, and self-organizing teams don’t appear on Day 1. Until those skills exist within a self-contained team, supplementing with traditional roles is fine. Project teams need to deliver, and adopting an Agile or traditional team formation is still influenced by the leadership team and the existing team skill sets. There are many different approaches to project execution, but I know which team structure I’d prefer!

6 Steps to Achieving Realistic Deadlines for Your Manufacturing Projects

6 steps to achieve realistic deadlines for your manufacturing projects

As a consultant, I frequently work with companies that lack a unified business process and struggle to deliver their projects on time. Even though I hear the same story time and again, I’m surprised by how so many organizations function in a state of constant chaos. It doesn’t have to be this way!

With just 6 steps, you can go from missed deadlines and isolated teams to a shared process and on-time delivery. Before I go into detail on these steps, it’s important to understand how companies get to a chaotic existence in the first place and when it might be time to re-evaluate your own business processes.

A Familiar Story

I was recently consulting with a large made to order (MTO) manufacturing company that wanted to implement a software solution to improve throughput and on-time performance. At first, it seemed odd to me that the solution got more push back from floor supervisors than the management. It turned out that the floor supervisors didn’t understand how their disparate processes were negatively impacting the business or how this new system would benefit them– what motivation did they have to change?

To get a sense for how each group was running their projects, I conducted a survey of the different spreadsheet programs that were being used. Most floor managers were using Excel to manage their projects and more than a few had become Visual Basic experts, proud of their current methods. I ended the survey early, since it was clear that each group was using an isolated solution and process that was completely independent of other areas of the business.

This created a massive problem for managers and executives–they had zero visibility! There was no central source of truth to see how project plans and workload interacted across the organization. It also created problems for the floor supervisors who were using siloed spreadsheets. Since different teams occasionally shared resources, decisions made by one team could have damaging consequences on another, leading to finger pointing and blame as opposed to communication and collaboration. Managers had to rely on emails, phone calls, or walking out to the floor to understand an order’s status.

My client needed more than just a process overhaul–they also needed to implement dynamic project management software that worked across the entire organization.

A-20_State_PM_CTA

A Process to Drive Positive Change

Over the years, I’ve found that the problems that exist in MTO environments mirror those in all other project management applications. According to a Gallup Business Journal article:

  • 39% of projects fail due to lack of planning, resources, and activities.
  • 57% of projects fail due to a breakdown in communications.

To overcome these two failures, I established a business process called Dependency, Variation and Analysis (DVA) that surrounds a dynamic project management software solution like LiquidPlanner. The DVA process has 6 components:

  1. A focused objective, such as “Delivering projects on time.”
  2. Clear metrics, such as “95% on time performance.”
  3. An agreed upon network with clearly defined tasks and resources.
  4. Captured variation in the form of best-case to worst-case task estimates.
  5. Establishing a completion date using “What If” analysis.
  6. A method of routine collaboration and communication.

Here’s how you can use DVA to improve your business processes and hit your deadlines.

1. Create a Focused Objective

One way to resolve conflict is make sure everyone knows why they are doing this work. It’s a simple one-sentence line, like deliver engineer-to-order projects to customers at our promise dates 95% of the time.

2. Identify Clear Metrics

The saying, “tell me how you will measure me and I will tell you how I will react” should drive your business process to make the metrics clear. Ideally, there should only be one or two metrics to focus on. Too many metrics can cause conflict because teams often sacrifice one to improve another. For project management, they are typically based on delivering projects on time and under budget.

3. Plan the Network

The floor supervisors in my example ignored the impact that their decisions had on other groups. They started working on tasks before a dependency was complete to keep their teams busy and looking efficient. If a change notice was issued, the task that shouldn’t have been started had to be re-done, causing confusion, extra expenditures, and lost time. This also often generated a fair amount of finger pointing between the groups.

Network creation begins with the project team coming to a half-day meeting. Every person gets a package of sticky notes, a marker, and the assignment of writing down the tasks they think need to be included in the network. These notes are then placed on a wall, and duplicate tasks and those that don’t support the objective are removed. The order of tasks is established from left to right, and any dependencies are captured.

If the project team is not all in the same geographic location, however, this step becomes a little more complicated. This is where LiquidPlanner’s works well. Cards with task names can be added by team members in different locations. The duplicate tasks can be moved to their own column or deleted. Then, planned tasks are assigned resources and dependencies. Many tasks compete for time on the same constrained resource, so creating a schedule in priority order is important when managing a constraint.

4. Capture Variation

Capturing variation in tasks is the next order of business. The only way to do this is to estimate using a range. LiquidPlanner is the only project management solution I have found that allows teams to plan with best-case to worst-case ranged estimation and includes the variation as part of its schedule calculations. Because the people who are actually doing the work are the ones adding the estimates, the plan is much more realistic.
It’s important to realize that the worst-case estimate can have the biggest impact on the duration of the project, so we ask for team members to be a bit paranoid, but not “crazy paranoid,” in estimating their tasks.

5. Establish a Completion Date using “What If” Planning

The first predicted completion date is generated using LiquidPlanner and includes dates for the entire portfolio. If the finish date doesn’t meet our requirements, the team goes through a “What If” analysis to determine if changing assignments, priorities, or adding help improves the lead time. This “What If” process only happens once during a routine meeting (we’ll get to these meetings in the next step). By the end of the meeting, we have a solid plan in place that all stakeholders agree on.

6. Schedule Routine Communication

Once the network in place, a process must be established to keep projects on pace with their deadlines. This is accomplished with a daily 15-minute meeting focused only on projects that are in the red and strategies to get them back in line. The results of the meeting are recorded as a comment in LiquidPlanner. Team members that can’t attend the meeting update their estimates and leave comments as well. Having all team communication in one place increases clarity and eliminates the need for managers to chase people down in pursuit of answers.

Getting Results

Change is always hard, but it is necessary to get the results you want. My clients that implement the DVA process along with a dynamic software solution like LiquidPlanner see on-time performance reach or exceed 95%. They also notice a significant emotional shift across the team as chaos, conflict, and confusion are replaced with focus, clarity, and teamwork. Of course, increased profitability doesn’t hurt either!

If you would like to learn more about the DVA process and how I can help your organization establish a unified process, visit www.kohls-consulting.com.

Kevin Kohls has been using the Theory of Constraints in business for almost 30 years.  He developed GM’s Throughput Improvement Process (TIP), and is a past winner of both the Franz Edelman Operations Research award and the Boss Kettering Award for Innovation. He is current writing “Addicted to Hopium”, describing how to set up and run profitable improvement processes. 

Interested in learning more about LiquidPlanner’s dynamic methodology? Download the eBook, “Introduction to Dynamic Project Management.”

An Introduction to Dynamic Project Management

How to Scale Methodology for Your IT Project

project methodology

If you’ve worked for an organization of any size delivering software projects, you’ll eventually be asked to follow a methodology. In small organizations, it could be a common set of steps that are “light and nimble.” As the organization grows, more steps are added, additional teams are consulted and before long—you’re got a full-fledged methodology to manage.

Methodology is a tool, not a torture device designed to inhibit project teams. Methodology provides guidance across an IT organization in order to successfully deliver projects. As much as project managers like to control all decision-making in a project, there are times when IT project managers need to engage other IT teams like Architecture or IT Security. A few examples include:

  • Launching a new website
  • Working with systems that contain confidential or personally identifiable data
  • Ascertaining whether or not the server can handle all the traffic

In the following examples, team leaders probably should check with IT Security, Architecture and the Infrastructure teams while moving through a project. If you’re new to the organization, a standard methodology helps guide you on how to engage these teams to get the information you need, and give them a heads up about what’s going on that affects other departments.

When Teams Resist a Methodology

Here’s an example that might sound familiar: A project management office (PMO) or senior leader publishes standard steps, establishes checkpoints (tollgates) and project audits to ensure teams are compliant with the process. At the same time, various project teams squirm to explain why their project is different and how the methodology doesn’t fit. Agile project teams start waving the “Hey we’re Agile” flag and want the team to decide on the right processes and tools for the project, instead of a third party organization making process decisions.

Successful organizations will scale the methodology based on the complexity of the project. Methodology teams produce methodology frameworks to ensure teams follow a consistent process that integrates all IT and business stakeholders. However, projects differ in scope and complexity so the methodology should adjust accordingly.

The best way to align the methodology with the delivery team is to tailor the methodology to fit the project. Much like tailoring a suit, the process leadership and project teams work together to apply the processes that best fit the project.

Below are six steps your teams can take to successfully scale your methodology:

Step 1: Define the Methodology

If the organization is well defined, there should be a published methodology with all the processes, activities and templates needed in order to deliver a project. Some organizations publish a loosely structured framework and others have perspective steps based on the type of software project—Waterfall, Agile, a combination; Software As a Service (SaaS) or Commercial Off The Shelf (COTS) packages.

Step 2: Identify mandatory and optional components

Review each process step, deliverable and template. The methodology will outline optional steps and the ones that are mandatory. With an increased focus on security and cloud-hosting, security scans and infrastructure assessments should be mandatory.

Step 3: Develop a tailoring process

When project teams implement projects, they want to know which processes are required and how to adjust the methodology to fit the project. Developing and communicating a tailoring process will help your team understand how to scale the methodology. Below is a generic tailoring process that includes the project manager, the PMO and any shared service team like security, architecture and infrastructure. If your organization doesn’t have a formal PMO, I’m sure there is someone overlooking overall quality and ensuring common processes are being followed.

project tailoring

Step 4: Tailor the Project

By reviewing the processes and deliverables upfront required to deliver the project, everyone has a common understanding of expectations. If a process step doesn’t make sense, remove it but at least get agreement from the key stakeholders in the IT organization.

If you’re deploying a new Internet facing website, you’re better off making the security scan or IT security review mandatory versus optional. However, if you’re delivering a second release of an existing software application, the project charter is likely optional.

Step 5: Execute and Adjust

Based on the tailoring document, the project will create the appropriate deliverables. During project execution, if a step no longer applies or if a step needs to be added, simply adjust the tailoring decision document and review with the process owners. In formal gate reviews, the tailoring decision document confirms that the correct processes are being applied, so it’s important to keep that document updated.

Step 6: At the end of the project, review and refine the methodology

It’s important that the project team provides feedback on the process; regular feedback helps improve the methodology over time. No one wants to be accused of “sitting in an ivory tower” and dictating process without understanding the impact. For example, the project team might find redundant processes or identify improvements to project templates. Over time, similar types of project tailoring will emerge and the organization can publish these tailoring decision documents as scaled versions of the methodology. Your organization will find the methodology will scale for outsourced IT projects, infrastructure projects, COTS implementations, business process outsourcing, Agile and traditional waterfall projects.

Methodology is a tool

Remember, methodology is a tool to help align all the IT teams and their respective processes. One tool isn’t a fit for every project so adjustments need to be made to ensure project teams are delivering in the right direction. Security, architecture, IT compliance and infrastructure teams all want projects to succeed and they define processes to ensure success.

The PMO or a senior IT leader’s job is to help standardize and communicate these processes as projects execute. Project teams can still be reluctant to follow a singular prescribed process. The best way to scale your project for success is to scale your methodology to fit the project and then agree to all decisions up front.  Remember: establishing a methodology, especially one that can flex to the changing needs of teams, is a tool to help teams deliver excellence.

Addressing, selecting and getting adoption on a methodology is one of the challenges to project management. To get more solutions to classic PM issues, download our eBook, “How to Solve the Top 9 Project Management Challenges.”

How to Solve the Top 9 Project Management Challenges

6 Top Project Fears that Dynamic Project Management Makes Disappear

top project fears

There’s a lot at stake for project teams and their managers. Big money’s on the table, commitments and partnerships have been made, and there’s a network of teams with skilled workers who are coordinating their efforts to make timely hand-offs and deliveries. In short, there’s endless stuff to accomplish and stay on top of. And if you don’t have a fast and flexible tool that helps you manage and track everything–you have every right to be very, very afraid!

However, if you institute the right project management process, you don’t have to stay up at night worrying about your project (or your business, or your job). Here’s a look at how swapping old-school project management processes (spreadsheets, non-collaborative tools) for a dynamic project management system can help you overcome six terrifying but common project management situations.

1. “I don’t think we’ll make the deadline!”

It’s not fun to sweat out a project because you established a single-point finish date that was A) established by a boss or client with no idea of how long each task would take, and B) didn’t account for unexpected risks that are now taking the project in a whole new direction. Big oops! A dynamic project management process lets you make ranged estimates based on best/worst case scenarios. This practice schedules uncertainty into your plan, and gives teams a range of finish dates that are based in reality—because the people doing the work are making the estimates.

2. “My team is putting in too much overtime again—I hope they don’t quit on me!”

An over-scheduled team is an unhappy (and eventually unproductive) one. The antidote to this is finding a system that integrates resource leveling into your scheduler. This way, as you create your project plan, the schedule will be built based on team members’ availability. No over-booking, no over-working. A happy, engaged, productive team.

3. “Did they get my email? Do they know what’s happening over here?”

It’s hard to establish impeccable communication streams when everyone is using a different tool to share information: email, chat, text, phone, video . . . But when everyone is working in the same tool, having conversations in context with the work being done, you create a storyline for your project work. This eliminates blind spots and unpleasant surprises; instead, any schedule shifts get communicated ASAP to the people that need to manage the changes.

4. “What on earth is my team even doing?”

The silos of spreadsheets and other static tools that are managed by one person make it hard to keep track of projects in real time. (Plus, they’re so hard to update, they’re hardly ever updated!) A dynamic project management tool is collaborative. It lets everyone participate in updating their work, inputting time and estimates to each task, and handing off or closing tasks. When all project information is stored in one place and updated automatically with every change, it’s easy for managers to eyeball the schedule and see who’s doing what—especially when you have a resource workload report surfacing team members’ activities.

5. “How do I keep my team focused on the right priorities?”

A dynamic project management process makes it easy to prioritize work—and re-prioritize work as things change. And here’s the best part: The tasks are clearly visible to all team members, so they know at all times what the top priority work is. Better yet, using a transparent tool means everyone can see how their work relates to the bigger picture, which builds engagement, autonomy—and top-performing teams.

6. “How do I stay connected to our global offices?”

Using online project planning software has the benefits of being accessible to anyone on the team, anywhere in the world. You could be working two feet away from a team member or across the globe—the work all shows up in the same place. Just account for time changes.

Could you benefit from adopting the Dynamic Project Management system? Take our project management diagnostic to get a sense for the health of your current project management system.

Start the assessment!

One more thing! Interested in learning more about the benefits of using a dynamic project management process? Download our eBook, “Introduction to Dynamic Project Management.”

Intro to Dynamic PM

 

 

Why Is Six Sigma Important to Manufacturing Teams?

Six Sigma

Anyone who has ever led a manufacturing project can attest to the fact that they have unique challenges. Nearly all projects iterate through some version of the “planning, execution and control” cycle, but manufacturing takes that to new levels. This is particularly true when you are going to be churning out a high volume of the same thing, such as an automobile part or an electrical component.

Watching the end result of a project manifest itself as thousands (or millions) of an item rolling off of a conveyer belt can elicit an almost Zen like pleasure. But it also can be accompanied by a sinister side effect: variance. Variance is the enemy of production, but the trouble is that virtually everything varies somewhat in this universe if you measure it carefully enough. There are simply tiny fluctuations present in everything we see and touch. This includes even the most precise goods made today. Addressing variance is where the processes of Six Sigma shines.

What’s a “Sigma”?
Six Sigma is a group of processes that were born at Motorola and made famous at General Electric. Now it is used in many of the best manufacturing companies around the world.  Before we get into the specifics of what Six Sigma is and why it’s important, let’s discuss what a sigma is and why it matters.

When you are manufacturing a product, standardization matters. In fact, whether or not the product is a “quality” product depends upon the product falling within a certain range of specifications.

As stated earlier, everything deviates from a standard if you measure it carefully enough. The goal is to take measurements that are fine enough to capture these fluctuations. You average these measures together to determine the mean, and then you can calculate the standard deviation of all of those numbers. This simply tells how diverse your data set is. Diversity can be a good thing but not when you are dealing with products that are supposed to be standardized!

Ideally, your measurements should be grouped very closely to the mean. This would indicate a low standard deviation, which is desirable. On the other hand, a high standard deviation indicates a lot of variance, which means your processes are probably not under control.

This is where we get the word “sigma.” A sigma, abbreviated as “σ“, represents a distance on either side of the mean.  A single standard deviation from the mean is called “one sigma.” So one sigma quality means that only the items with measurements that fell within one standard deviation passed quality inspection. Unfortunately, this only equates to about 31 percent. Three sigma quality is much better since it means that many more passed through quality. That gets us up to over 93 percent quality.

If you have achieved six sigma quality, you have only 3.4 defects for every one million products that your organization produces. This is considered to be world class.

world class
What Six Sigma Looks Like in the Real World

One way it has been described is that one sigma quality equates to an error per page in a book. Three sigma quality equates to a single error in the whole book. Six Sigma quality would have only a single error in the entire library. When you achieve the level of six sigmas, you have essentially removed most of the things that can be controlled. Remaining defects will fluctuations in line with the nature of materials, etc.

The 5 Steps of Six Sigma

But the goal is not simply to achieve this quality. The goal is to be able to achieve it repeatedly and predictably every time you manufacture the product. This generally involves not only the organization performing the project but also the entire supply chain.  So Six Sigma has a series of steps to help you achieve world class quality and sustain it. This family of steps is abbreviated as DMAIC. If you work around Six Sigma, you will see DMAIC a lot. It is an acronym that stands for:

(D)efine
(M)easure
(A)nalyze
(I)mprove
(C)ontrol

Here’s a look at each step:

  • Data: The steps that make up DMAIC are based on hard numerical analysis and not simply observation. The team gathers data and those data are used to understand and make decisions. As W. Edwards Deming famously stated, “Without data you’re just another person with an opinion.”This data-driven approach begins with the step of Define. In other words, define the problem, define the scope, and define what success would look like. Steven Covey urged us to “Begin with end in mind”, and this is simply an empirical understanding of what that end should look like.
  • Measure is where you take very specific measurements of your current reality. This starts with the output but may grow to include measurements about how the output is being produced.
  • Analyze is about coming up with a plan to move from the current measured state to the desired state. It commonly involves root cause analysis so that you are not simply dealing with surface issues.
  • The step of Improve takes action to move the current state to the desired state. The previous steps of Define and Analyze are to gain an understanding of what is wrong and how to fix it, but this step takes real steps to bring the product into quality tolerances.
  • Control is about making your change consistently repeatable. This is not about a one-time fix. It is about putting the right change policies, and processes in place to produce consistently better products. This can be the most frustrating step in the entire process.
Prevention Over Inspection

A common reaction when looking at this list is: “What happened to inspection?” In other words, how can you have high quality if product inspection is not an integral part?  The answer is that Six Sigma, like most modern quality programs values prevention over inspection. It is based on the principle that quality cannot be inspected into a product after it has already been manufactured. Instead, quality is all about prevention. When it comes to delivering quality products, planning always wins over inspection.

The art is to learn to identify, measure, and ultimately eliminate variances. And this is not a one-time activity. It has to be done throughout the project and into subsequent operations, because waste is like weeds in a lawn or garden. You get rid of the undesirables but then they inevitably and relentlessly come creeping back in.

Is Six Sigma Right for Your Project?

You can best answer this question by looking at the type of manufacturing or service delivery involved in your project. In cases where the manufacturing is not highly consistent, it may be best to try a different approach. A great example of a Six Sigma project includes Motorola manufactured circuit boards and silicon processors and chips. This was highly repetitive and did not vary much within a product line. On the other hand, consider an aircraft manufacturer that delivers a relatively small quantity of planes that are each configured differently—not a great candidate for Six Sigma?

Taking the steps to achieve world class quality can be intimidating, but it brings big rewards. If you are ready to learn more about Six Sigma and what it can do for you, the American Society for Quality could be a great place for you to begin.

Did you know that only 2.5% of companies successfully complete 100% of their projects? That’s sign of a bad project management process. How would you rate yours? Take our Project Management Health Check, a 9-question multiple-choice assessment of your project management process.  

Take the assessment!

4 Ways Project Management and Lean Manufacturing Speed Up Processes

lean and project management intersection

Lean manufacturing has become a popular way to eliminate waste, reduce costs and improve efficiencies. This philosophy originated, largely, at Toyota and is used to better align customer needs with manufacturing operations.

The challenge with lean is that, despite its attraction to many executives who want to cut costs and increase productivity, a lean process doesn’t happen overnight. There are plenty of obstacles to overcome—obstacles that are almost identical to the challenges of implementing projects successfully.

Even though lean and projects have these implementation challenges in common, my clients waste quite a bit of effort debating whether lean and project management can work together, or whether they’re at odds with one another. Of course, this conversation goes against the point of lean—to eliminate unnecessary waste—yet it occurs frequently. After 25 years of leading manufacturing operations, implementing lean principles and conducting hundreds of projects, I can assure you that the opposite is true:

Lean is supported by the basic tenets of project management.

The intersection point: a vast opportunity!

There is a point of intersection for lean and project management that will deliver substantial bottom line business results—growth, profit, cash and margin. But there has to be a level of commitment for this to work. Lean requires continuous, short spurts of excellence in execution and focus to accomplish results. To achieve this goal, you need resources, team involvement and collaborative goals. The reality is that most lean programs fail as executives lose interest.

Instead of creating these lean execution systems from scratch and letting the excitement wear out before meaningful success, the most successful organizations leverage an already-existing base that springs from project management fundamentals. Strangely enough, teams rarely follow this path because they think that lean and project management cannot play in the same sandbox. Those companies are losing out on a vast opportunity!

How do you take advantage of this opportunity? By knowing when lean and project management approaches work together, rather than in opposition. Here are four examples of how lean manufacturing principles and project management approaches intersect, and make your process faster and better:

1. Focus on the customer

One of the most important aspects of lean is the focus on the customer. Instead of creating elaborate systems to figure out demand, the idea is to find the most direct route to the customer and pull the demand. Here, “customer” doesn’t necessarily mean the end-user customer; lean principles view the customer as the next person to receive your work. Your customer can also be the person on the line if you’re a support role to the line (thereby including management). In other words, focusing on the customer can flip thinking upside down.

My most successful projects followed this same rule. When following the critical path, you should be thinking of what your customer (next person on the critical path) needs and when they need it by. Ask yourself: “What can I do to provide value within this critical path and how can I make sure work continues to move (flow) through the critical path?” These are project management principles.

2. Focus on value

Another of the key tenets of lean is the focus on value. Instead of getting caught up in non-value added yet wildly popular fads of the time, the idea is to focus on what will create value. Actually, lean manufacturing in itself is sometimes viewed as a fad. For example, I’ve had clients who want to implement lean principles, and at least 60 percent of the time these executives see it as a quick fix: Coordinate a few kaizen events, and the company will be in great shape. This is never a successful strategy!

Project management is the same. Spending days on project charters, complicated project plans and different resource task lists is useless if value is not at the crux of the plan. In project management, the key is to focus on the critical path. The critical path will align with those tasks providing value that will add up and achieve your end objective. Following the critical path aligns with how to implement the future state value stream map.

3. Be more Agile

Agile is at the intersection of lean and project management. An Agile approach allows you to break down lengthier projects with complex components into reasonable chunks. Agile yields a quicker process, as you’ll gain rapid feedback on the first chunk of work (which could relate to a milestone), rather than waiting to the very end and making complicated changes to the finished product. With Agile, you can incorporate continuous feedback into each chunk of work, or sprint, so that you continually improve the process as you go along.

In lean manufacturing, this same principle applies as you perform a kaizen event. The objective is to have a reasonable and achievable amount of work that will provide an end result that aligns with a step towards your end objective within a short period of time, typically a week. Once you perform the first chunk, you incorporate feedback and lessons learn into the next chunk. As chunks are added, layers of complexity are achieved. The bottom line is that smaller batch sizes of work are performed in an iterative fashion for the most successful lean and Agile approaches.

4. Give projects visibility

Lean manufacturing programs are known for making the process and associated metrics visible. For example, an aerospace manufacturer client I worked with had lead times of 6 -13 weeks involving several operations. It was complicated but critical to know if they were behind schedule long before the item didn’t ship on time and showed on a past due list. Thus, we chunked the work load into smaller buckets and hung work order packets on the wall by the machine or machine group. This provided visibility into whether a certain group of machines were getting overloaded. We also put problem orders into a separate section so they were immediately visible to everyone. Last but not least, we started showing the age of the work orders with color coding. This enabled us to manage work orders successfully.

The same is critical in project management. I’ve worked on countless project plans with hundreds of pages. Who can keep track of all that complexity (similar to the piles of work orders at my client)? Thus, my most successful clients have found a way to communicate project progress in relatively equal chunks of work with clear progress towards objectives in a visual way.

Often, this is supported by a project management tool with visibility into schedule. The result is a clear picture of a simple timeline with critical milestones in weekly or monthly buckets—and effectively show progress visually. Tasks that are ahead of schedule or behind schedule pop out immediately so that action can be taken. And, importantly, tasks that have been idle (no progress for a period of time) can be color coded so they’ll emerge and be visible.

A strong partnership for projects

Using lean and project management approaches together can take your production process to the next level. Instead of wasting time debating whether these two approaches can work together, look for the common elements. I see lean as uncommon common sense. And, in my experience, the most successful projects also followed uncommon common sense. If you focus on putting the best of both of these methodologies together (customer, value, Agile and visibility), business-winning results will follow.

In our latest eBook, “Are You Ready for the Fourth Industrial Revolution?” we take a look at what it means to be lean and thrive in Industry 4.0, and what tools are necessary to keep up with new world market demands. We’re going there right along with you!

Download the eBook now!
Are You Ready for the Fourth Industrial Revolution?

How to Solve the 5 Top Challenges of Manufacturing Projects

When you work on a manufacturing project, you face some unique challenges, often with a lot at stake. You have to deliver your product at consistently high-quality standards, navigate end-to-end supply chains and manage strict time-to-market deadlines driven by demanding customers or seasonal demands. To top it all off, the entire project might be following a process where design, scope, cost and time scales were fixed at the very beginning of the project—or it could be a first-time project so who knows how long parts will really take?

manufacturing problems

Here, we’re going to look at some of the challenges specific to project teams working in the manufacturing industry—and how to solve these problems using project management practices and a dynamic tool.

1. Managing Stakeholder Expectations

It’s always tricky to manage a disparate set of demands, visions and expectations on any project; but it’s even trickier in manufacturing. A common problem is that stakeholders have a tendency to set unrealistic deadlines and make unreasonable demands—and through no fault of their own, really. This happens because expectations aren’t set early on in the project.

For example, a stakeholder responds to a date the customer requests, without knowing how long it takes to complete the work. And then you’re stuck managing an overwhelmed team who has to work overtime, and maybe even sacrifice quality, feature requests or more. So how do you set stakeholder expectations realistically from the very conception of the project?

Estimate work and share the schedule

Get stakeholders involved from day one and make them a part of the process. Start by providing a schedule that includes thoughtful estimates for everyone’s work—by the people doing the work. If management challenges the timeline and wants the product launched sooner, you can have a data-driven conversation by using the schedule and estimates.

Encourage teams to estimate their projects as realistically as possible. Insert buffer-time and account for risks that might occur. When people estimate there’s a tendency to be over-optimistic which can set a team up for failure. Some teams invite outside experts to help them improve their estimation, and make use of methods such as ranged estimates or three-point estimation. Make the schedule accessible and visible throughout the project—so status is clear, and there are no unexpected surprises.

To share schedules, use a project management tool that offers a way to curate project reports with just the information your stakeholders need, like dashboards. This way stakeholders can keep up with everything throughout the project lifecycle.

2. Inflexible processes

Since manufacturing projects are highly sensitive to time, cost and quality, they can be extremely demanding to run. This often results in senior management asking for a very controlled and rigid project management framework to be followed. In my years as a project management consultant, I’ve observed in manufacturing of machinery, consumer goods, instruments and chemicals, that such a controlled framework has its place, but it can be a big challenge as well.

The downside of a controlled environment is that project teams have to commit to a solution and a timeline upfront. Consequently, they’re left with little scope to make adjustments as the project evolves and new information comes to light. Imagine for instance that you are running an 18-month project to design and produce a new type of consumer appliance and you have to commit to the design and plan very early on without the ability to later adjust it. Now that’s a challenge!

Use a dynamic scheduling tool and test early on

There is a way to address inflexible processes while still satisfying senior management’s need for control. Allow teams to experiment more up front and to iterate through the solution to prove the concept before they commit and lock down the design and manufacturing process. In other words, a longer inception phase with some trial-and-error, and with the view of driving down risk and uncertainly early on can be a win-win for all parties.

Build this time into your plan from the get-go. And use a scheduling tool that is adaptable and dynamic—one that updates automatically every time a change is made. This way the team can keep up with changes as they occur and respond accordingly earlier on in the process to meet hard delivery dates.

To keep your team a step ahead of fluctuating schedules, use a project management platform that builds uncertainty and predictive finish dates into the scheduling engine.

3. Change management

The more a team experiments and creates physical prototypes that can be assessed by their clients, the less likely their clients are to change their minds—or to ask for new features. But even the best of prototypes and the tightest of scope statements won’t protect against changes.

Change requests are an inherent part of product development, and they’re bound to happen—either because of wrong assumptions, unexpected constraints from the vendor, a change in the marketplace or a change in the client’s strategy. Imagine for instance that a new technological advance in the marketplace will make your planned product look markedly inferior. You have to respond, and make the adjustments. Otherwise, you could be working on a project that is out of date upon delivery.

Get buy-in for all hands on deck

If a project needs to be fast-tracked it’s imperative that the path of escalation is clear and that the project has an effective steering committee and decision-making forum. Research by PMI shows that senior level buy-in is one of the most significant factors for success on projects. Also, if the team really must deliver sooner than they’re comfortable with, the team leader can ask for dedicated resources all the way through the project and ensure that issues can be unblocked and decisions made swiftly by management.

Use project management software that integrates resource management features like workload reports and resource leveling into the project plan.

4. Ownership

A project might have many different departments involved during the project lifecycle, from market research, R&D, production to sales, marketing and distribution. For the project to be delivered successfully these different departments need to collaborate instead of operating within each of their silos. One particular decision that’s important to get right, is deciding who should lead the project.

In most cases, a technical project manager will lead the project because the majority of the effort is focused on designing and producing a technical product. But when a technical project manager is in charge, the risk is that he or she focuses on the technical aspects only and forgets about the business case, the market need, sales and distribution.

In some companies, project management responsibility is transferred from one department to another as the project passes through the different departments; but then, a sense of continuity and overall accountability suffers as no one has the end-to-end view.

Consider sales and marketing

Another option is to have someone from Sales or Marketing (or the commercial department) lead the project. Due to a strong commercial awareness, Sales and Marketing will find it natural to focus on developing the right product for the market and ensuring that the business case stacks up. These team members aren’t technical experts they aren’t equipped to lead the technical aspects of the project, but they can still be excellent owners of the project from beginning to end as long as they work with a strong technical lead.

In my experience, many organizations would benefit from choosing a project manager from sales and marketing, instead of forcing an excellent technical manager to also own the many milestones that aren’t technical.

5. Managing Supply Chain Complexity

Adding contractors, vendors and additional third parties to the production process increases the risk of error and miscommunication exponentially. Not only do you have production work occurring in different locations by different teams, each team might be using their own tracking software for their scope of work. Accounting for all the moving parts—materials, people, teams, quality, supply chains, product cycles, etc.—gets tricky.

Historically, manufacturing organizations have used tools that are driven by fixed start and end dates. They’re too rigid to accommodate the changes inherent to project and production work. The schedule is often overseen by one person, so the rest of the team—and teams—don’t have visibility into what’s happening. Plus, manual updates are laborious and can’t keep up with the rate of change. So, as priorities shift, and events occur that delay production or shipping, there’s no way for teams to see this reflected in the project schedule and react immediately.

Use collaborative software with visibility for everyone
The best fix for seeing what teams are doing across the production process and the globe is to find a project management tool that’s collaborative and provides visibility for all. This way, anyone at any time can access the project schedule, see where progress and status stands, and follow communication strings that relay important information.

This is the best front-line defense to knowing what’s going on with all your multiple vendors and manage dependencies. If all the vendors—and the project teams—can access the same project management tool, it takes away the blinders and lets everyone see how various aspects of the production are going.

Focus on the Work That Makes a Difference

Manufacturing projects are complex and filled with endless challenges—in a good way! The work is innovative, creative, hugely collaborative and global; and it’s all those moving parts that makes the industry such an exciting one to be part of. What teams need is a dynamic project management system that can respond as fluidly to the changes and unexpected occurrences that are part of manufacturing project life cycles. By taking out some of the stressful uncertainties and reactive demands, teams can focus on making a product that best meets the customer needs day after day.

Is your project management process working as effectively as it could? Find out! Take our Project Management Health Check, a 9-question multiple-choice assessment.  

Take the Assessment!