How to Work Together

The best way to help your PMO to become more agile, and vice versa, is to get these groups together and focus on their similarities instead of their differences. For example, both groups are interested in prioritizing projects to ensure that the most important ones receive adequate resources and budget. They are also concerned with project execution, though their definitions of success might vary between staying within budget and time constraints and meeting customer expectations.

When it comes to a difference of opinion, compromise is necessary. Creating an agile PMO in your organization will take a bit of diplomacy and mediation. It will be necessary to find ways to get each team to give a little ground for the greater good. For example, the PMO can compromise by being flexible and open to altering plans and schedules as needed, while agile developers can compromise by tracking their time in order to keep everyone updated on their progress.
Organizations with both PMPs and agile developers should not hesitate in getting these two talented groups to work together. With the right kind of management processes in place, managers can capitalize on the strengths of each group for successful project execution and increased return on investments.

Agile Development Is Here to Stay

Agile development continues to gain popularity in the IT world for a number of reasons. One of its key principles is constant communication between developers and customers, which helps in maximizing customer satisfaction and managing scope creep intelligently. Recently, an executive at a well-known financial institution told me that agile is important because it allows developers to build and demo often, enabling customer advocates to note when something needs to be corrected.

Agile allows companies to keep their fingers on the pulse and adapt themselves to the needs of customer or the market very quickly. "Agile teams are cross-functional, self organizing and self managing," Sulaima asserts. With principles such as these, it's not difficult to see how agile development teams can be extremely effective.

Joint Business Value

Combining the strengths of the PMO and the development team is a smart move. With a PMO to keep an eye on things, project risk can be managed much more effectively. Problems along the way are recognized and often resolved in a timely manner. In addition, the agile group can help the PMO to become more flexible and customer-oriented. Recently, Evan Campbell, CTO and agile devotee, was quoted in a project management article as saying,

"A strategic PMO can be a great asset to agile teams," notes CTO and agile devotee Evan Campbell in a recent article, "[... by] keeping an eye on performance of company assets in the portfolio and working with the product owner and scrum master to make sure the metrics of projects are assessed and value is delivered."

Agile development is often interpreted as completely at odds with the structure and constraints of the project management office (PMO). Yet it does not have to be this way. Creating an agile PMO that bridges the gap between these two significant groups can help organizations to prioritize projects and allocate resources much more effectively. Here's how to keep both project managers and agile developers happy while leveraging the strengths of each for successful project execution.

Who Needs a PMO Anyway?

The PMO brings significant advantages to the organization. For one thing, its focus on metrics is often crucial to the health and success of a project portfolio. It can also facilitate communication between project team members, project managers and those higher up in the organization. Tamara Sulaiman, a project management consultant, explains it this way:

"Let's say you are a manager or leader in an agile organization. Your development teams have implemented Scrum and are now working toward release. You've got the Scrum of Scrums working so that teams can communicate with each other about cross-team dependencies and impediments on a daily basis. But there's a gap, isn't there? As a manager, how do you effectively and efficiently measure progress, manage risk and keep your eye on the big picture across these agile teams? Wouldn't it be great to have an easy way to communicate budget and schedule information at the program level to the organization?"

While the agile worker is focused mainly on development at a fast pace, the PMO can help to keep the rest of the organization informed about what is going on. Scope changes, delays or quality issues can arise at any time, and when they do, they must be communicated to all of the stakeholders who can adjust expectations accordingly and take the appropriate course of action.

Let's finish off our week of focusing on IT Projects with a CIO article that offers some keys to success that might be overlooked by project managers.

What's the recipe for project management success? Many IT professionals agree that buy-in and support from top management, clearly defined scope and requirements, good communication, and the right project resources top the list of key ingredients.

Those aren't the only factors influencing the successful outcome of a project, of course.

According to 83 members of the CIO Forum on LinkedIn, here are some "less-considered" keys to IT project management success:

1. A Clear Definition of Success
2. A Willingness to Make Unpopular Decisions
3. End-User Training and Hand-Holding After Go-Live
4. Clearly Defined Roles and Responsibilities
5. Transparent Workflows
6. A Process for Managing Scope Changes
7. Risk Management
8. Adequate Documentation
9. A Good QA Process
10. Project Governance

Can you think of any other factors that are often overlooked, but impact the success of projects nonetheless?

In continuing the series, here are the highlights from Schultz's newest article on change management and technology for managing IT projects successfully.

11. Change Management

Good – I lead the project team in addressing the introduction of new business processes and their impact on staff.

Bad - The project team is not introducing new business processes, despite my encouragement as project manager, to place more emphasis on this topic.

Ugly - The project team doesn’t believe change management is required.

12. Project Technology

Good - The project consistently uses a short list of technologies. I can conceptually describe the technology.

Bad - The project uses an extensive and changing list of technologies. Initially it was Microsoft; some months later it’s Java and more recently something called LAMP is being discussed.

Ugly – I observe the project team using lots of technology buzzwords in discussions. It’s not clear what technologies the project is actually using.

Anything you would add to Schultz's lengthy list of factors that go into IT project success?

As you might remember, we've been following Yogi Schultz's Project Times series on what it takes to execute IT projects successfully. In Part 1, he discussed project goals and sponsors. In Part 2, he focused on the project manager, benefits, plans, status and budget. Part 3 gets into some new issues:

7. Project Organization

Good - I've created a reasonably clear organization chart with names and titles.

Bad - I've created more than one organization chart with many lines. Some names or titles are missing.

Ugly - I’m not clear who is on the project team.

8. Project Resources

Good - Most individuals on the project organization chart are assigned full-time and are employees.

Bad - More individuals are part-time or contract staff than are full-time employees.

Ugly - We’re using the virtual resource concept.

9. Project Steering Committee

Good - I ensure that key business areas that will be affected by the project are represented on the project steering committee.

Bad - The committee doesn't exist as far as I, as project manager, can tell.

Ugly - Committee membership is unclear to me or meetings are sporadic and/or offer little content.

10. Stakeholder Communication

Good - I’ve ensured effective communication to the various stakeholders.

Bad - The communication to the various stakeholders that I’ve witnessed is sporadic.

Ugly - I’ve not observed effective communication to the various stakeholders.

Remember when we posted about the competition between scrum and waterfall? Elizabeth Larson is back with a second part to her article on which method is "winning." In this installment, she highlights the similarities between the two:

1. Both have processes to request, approve and prioritize changes. Both put focus for the approval and prioritization on the Business (product owner/sponsor/SMEs).
2. Both stress the importance of communications.
3. Both allow for more or less rigor, as appropriate.
4. Both find communications easier when the teams are co-located.
5. Both face more challenges with virtual teams.
6. Both have processes to manage the scope.
7. Both estimate the work involved in business analysis whether phase (s), releases, iterations/sprints.

She also gives waterfall the advantage in a few scenarios, including effectively using the role of the BA to define requirements, defining the business need and business case, and getting from the "as-is" to the "to-be." Do you agree?

We recently featured a story by Gartner analyst Donna Fitzgerald on why EPMOs are becoming so important. Mike Gorsage at Inc Magazine agrees.

Cut a piece of wood hastily, and it will likely be ruined. That’s why “measuring twice and cutting once” is a carpenter’s golden rule. That same rule applies to implementing and managing business projects or programs: double check your work to understand every project aspect before you launch.

It's clear that successful project execution eludes many of us. So many people are asking, "How can I get my projects in on time and on budget?" Project failure is all too common and it is really hurting the bottom line for many companies. It's clear that a renewed focus on execution - RESULTS - is necessary.

A new article at CIO Magazine highlights 4 ways to get flagging projects back on track. If you find that project scope keeps changing, deadlines keep slipping and it's all getting away from you, it's time to:

1. Assess the situation
2. Prepare the team for recovery
3. Develop a game plan for recovery
4. Execute the game plan

Question: When do you prefer your warning signs: 2 weeks in, or 2 weeks away from your deadline? I'm guessing 99% of you would choose the former so that you could actually use these steps to fix things before too much time and money is lost. If that's you, I hope your team members are tracking time!

The most common result of this ‘evolution’ is that a lot of current projects are being carried out, yet no one can remember when they started and, even if some target date has been set, no reasonable expectation exists that they will end soon. The way to solve this is to increase awareness, including:

1) A recognition that IT projects do not belong to IT, they belong to the enterprise as a whole, even if various non-IT parts of the enterprise are assigned responsibility for some sub-set of projects.

2) An understanding that projects still originate the same way: a problem, challenge or opportunity is identified, or a new idea to improve the business is suggested. Sources for suggestions range from front-line staff to objectives stated in the enterprise’s strategic plan.

3) The realization that dozens or more project ideas may be in play at any one time, but the average enterprise does not have the resources to do them all. It must pick from the candidates which projects will indeed be resourced and proceeded with, and it must continue to do this as current projects are completed and resources are freed up.

It all boils down to best use of limited resources. The term that has emerged to describe all this is Project Governance.* The most common analogy used to describe this governance is “gating”: a number of things, like project ideas, enter into a process at its ‘wide’ point, but only a small number emerge through the narrower gate at the end of the process. The projects that make it through the gate are initiated, while the rest wait for another chance when more resources are available or are eventually dropped from consideration.

It is the nature of IT projects that their size and cost start out small, but increase in size as they proceed through standard Analysis and Design tasks into actual development (commonly called Construction). As a result, a mature governance process will be comprised of several gates that continue after a project has been initiated. More will be known about the project as it approaches the next gate, where it is evaluated again to determine if it should continue. Sometimes a project will have made it through one gate but, after proceeding for a period of time, more information has been gathered and it is clear at the next gate that the original decision to proceed is no longer viable and the project should be stopped. This is NOT a project failure. It is a success of the governance process to prevent wasting precious resources on continuing a project that will not be of value to the enterprise.

--

*In some ways, governance of IT has emerged a lot sooner than the newer Corporate Governance that deals with all aspects of a company’s operations in order to meet with new compliance laws brought around by the Enron failure and the like. Many IT departments already recognized they had their own mess to deal with, hence Project Governance.

David Wright has been an IT Business Analyst for 25 years and is the author of Cascade: Better Practices for Effective Delivery of Information Systems in a Multi-Project Environment. You can find more of his writing in the latest issue of Cutter IT Journal and at his blog, Business Analysis. You can also follow David on Twitter.

IT projects have rightly earned the reputation over the years as places where lots of money goes in and no value comes out. We are all aware of the CHAOS studies by the Standish Group that show that most IT projects are also usually late, and a large number are never even completed(!).

How did this happen? My (untested) theory is that computers were first used to automate rote manual tasks, and the results from these projects were valuable and easily seen as so. This led to the belief that automating most anything was going to be good for the enterprise, but as projects moved into more complicated/complex aspects of the business, the returns of pure automation began to diminish. Unfortunately, it was still assumed that the value was there, and it was a complete assumption; actually determining what the value was to be was done only rarely.

Early computer projects were really run in the realm of the IT department, likely better known then as the Data Processing department. Business departments had been happy to get their worst drudge work automated, but the techie geek image of IT started at this time as well, so the business would deal with IT as little as possible to get what they wanted, but otherwise considered IT as being on another planet. In this environment, one idea about using computers could snowball into a big project if enough people liked it.

So, projects proceeded into more complicated areas of the business, and they started to break down. Some failed, and now management wanted to know why, and also started asking if all these computer projects were worth what they cost (because costs were not assumed, they were measurable). How did they all get started anyway?

Come back on Friday for Part 2 of David's post on choosing the right IT projects!

David Wright has been an IT Business Analyst for 25 years and is the author of Cascade: Better Practices for Effective Delivery of Information Systems in a Multi-Project Environment. You can find more of his writing in the latest issue of Cutter IT Journal and at his blog, Business Analysis. You can also follow David on Twitter.

Donna Fitzgerald, Research Director at Gartner, recently blogged about the Enterprise Project Management Office and its importance to the organization:

[T]he role of the EPMO is to help the organization make sure that strategy (real strategy, not just words on paper) is realized through investment in projects and programs. If you are tempted to say “Come on, Donna — that’s what we do now,” then you are either in the 5 to 10% of companies where it is true, or you are mistaking the concept of “strategic alignment” for strategic realization. One says I’m somewhere in the general vicinity of the strategy — the other says I have direct line of sight to the strategy and can tangibly show how this project or program contributes.

She emphasizes that this model is different from what you might have read about EPMOs - it is "small, lean, mean and agile."

Do you have an EPMO? How does it perform in terms of helping you to reach your strategic goals?

--

Related stories:

TechNewsWorld: Why Should We Let Your Department Live? PMO Survival 101

Harvard Business Review: The Execution Trap

Project Times: Getting Strategic Projects Off the Back Burner

Project Times writer David Donaldson has highlighted the difference between education (transfer of knowledge) and training (transfer of skills). One aspect of training that is not involved in education alone is hands-on practice.

Tell. That is education, a critical first step. We need to know what we are doing.
Show. This is perfection. We know it, now we see how it is supposed to be done.
Do. This is where true learning happens. A student who can demonstrate a task now truly has the skill.

So how can you decide whether or not education is enough? According to Donaldson, training should always come into play.

At great expense we have built the perfect machine for the job, but if no one is trained how to operate that machine it will surely fail. [...] When considering the necessary elements of a successful project, remember, the proper amount of education coupled with quality training is an investment that will pay dividends.

InformationWeek has published an article on how to implement an analytics methodology for better decision-making.

Decisions made based solely on intuition, gut feelings, and years of experience, while valuable, tend to be less effective than scientific methods. Analytics provides a methodology that incorporates crucial variables and provides simulations that show the impact of our choices before we implement them.

The steps include:

1. Define the problem
2. Identify relevant factors
3. Focus on data collection and preparation
4. Model the solution
5. Report the results
6. Implement the decision
7. Follow up

Does your current decision-making process include these steps? How could you implement them in order to enhance what you're already doing?

Positivity is not often listed as a key characteristic for project managers, but ProjectConnections writer Carl Pritchard believes it is essential. In his latest article, he talks about how he and his wife went to see the Dalai Lama speak and how he continued to focus on the positive, even when audience members tried to get him to talk about depressing things.

How does all this tie back to our project worlds? As project managers we have amazing opportunities to create something new, to experience the capabilities of others and to construct legacies both personal and organizational. We create artifacts. We engage others. And it's very easy to drop into a mode where we focus on the challenges, the adversity, and the hills yet to climb, without looking back on the landscape that we have already altered. The amount of opportunity and power that affords us in our profession is staggering. And the ways in which we exert influence can be staggering, as well.

How can you be more positive when managing projects and interacting with team members and stakeholders? Would it make a difference to the success of the project?

We at Journyx would like to wish our friends in the United States a very happy Independence Day. Hopefully you have today off from work despite it being the 5th of July. For those of you who don't, we won't make you read the typical project management and business improvement content.

In a meeting last week, a Journyx manager brought up the story of the American Revolution. The British came out, all lined up, with better equipment and better numbers, and the colonists, who were shooting from behind trees, won the day. The lesson here is that perhaps you don't have the strongest sales numbers right now. Perhaps morale is down from having lost employees and clients. Perhaps your company is concerned about the new challenges that will come when the recession is over but all top-line growth strategies were cut last year.

Not to worry. Keep fighting. A great woman once quoted Arthur Ashe to me, and it still resonates: “Start where you are. Use what you have. Do what you can.” It's not the time to lie down and give up. It's the time to take responsibility for your company's welfare and success, regardless of your level or role. Step up and do something you can be proud of!

A new Project Times article has highlighted the reason why traditional PM methods and agile methods for risk management collide. The author notes that both are valuable, but he supports the agile way for the following reason:

The variability in complex software projects is what undermines traditional risk management in my view. We try to expend all of our effort in up-front risk management. Rather, we should expend most of our efforts towards figuring out what we do and do not know. We should decide how to design and code this particular widget I.e. do some of the project work before trying to predict risk. Let the risks emerge from our efforts rather than trying to predict them.

What's the best way to go about integrating traditional and new agile methods, both in risk management and in other areas? The best way is to find common ground and understand exactly which aspects of each best apply to your particular organization.

Admit it - you've always wanted to know a little bit more about your friends at Journyx, the people who make your life easier by providing the top web-based solutions for time tracking, invoicing, project accounting, resource management, cost reporting and more. Well, the wait is over. Over at the Journyx Facebook page, we are honoring our valued (and quirky) employees via...

The Journyx Employee Hall of Fame!

Head over there now to learn more about Scott, our Grumpy IT Guy, or Troy, our less grumpy Technical Support guru. Better yet, "like" Journyx on Facebook so that you won't miss all of the other employees who are yet to be featured. (We will pretend that you are doing so for sheer love of Journyx and not for the chance at an iPod Touch.)

Lisa Anderson asks the question in her latest article at Project Times.

In my experience in working with multiple companies across multiple industries and globally, I’ve seen many projects succeed while others fail. Although there are countless types of projects, ranging from a new product launch project to a system implementation project, there doesn’t seem to be a pattern of success among the same type of project. Instead, I’ve discovered that one of the hidden keys to success is vision.

She goes on to write that vision involves seeing the integration points and impacts, the optimal sequencing pattern and impacts, and potential roadblocks. "Practice improving your ability to see (vision), and emphasize and value this skill with your project team. You’ll not only deliver significant project results but you can utilize this skill in your personal life as well to achieve amazing results – why not give it a try?"

How do you use your vision to stay on top of potential problems and anticipate results?

Cloud computing has become incredibly popular in recent years, and its popularity is only going to grow. In fact, Journyx CEO Curt Finch \& Resource Manager April Boland recently published an article in Accounting Software 411 Insider on the future of cloud computing and why businesses simply can't ignore it.

PM World Today is also sounding the call with a new paper, "Cloud Computing Meets Project Management." The authors, Raj Asava and Hussein Mzee, argue that cloud computing is beneficial for project managers, but must be guided by tried and tested PM principles:

From lost time to inconsistency, the lack of process \& tools for managing projects will mean poor performance and an inability to harvest the true benefits of the cloud. The key to successful project management in the cloud era is to maintain the standardized project management framework that embeds best practices into how one manages projects, inside and outside the cloud.

The authors suggest that you harness the power of the cloud without forfeiting the processes that you've found successful in the past. This makes a lot of sense, though as project management continues to be influenced by the cloud's innovation, perhaps methodology will be influenced as well.

We interrupt your regularly scheduled project management content to give you this special bulletin:

Journyx is giving away an iPod Touch to one of our lucky followers on Facebook. To enter, all you have to do is "like" our page. Everyone who enters will receive the latest, greatest Journyx news, along with funny videos, tech and time management tips, and other tidbits to generally brighten your day. You will even get a behind the scenes look at the folks who keep your favorite software up and running each day.

This giveaway is our first but it won't be our last, so like us today - you won't regret it!

Project/initiative failure seems to be par for the course these days. Many of us are familiar with The Standish Group's findings that 2/3 of IT projects fail each year. In fact, there are even blogs and websites concerned solely with project failure. It might not be surprising, then, that Project Times reports a 66% failure rate in strategy execution.

Why is it so hard to simply get things done? (That's a loaded question we'll save for another time.) Ruchira Chatterjee at Project Times believes that the solution can be found in program management:

In addition to project and portfolio management, the community of project practitioners is now looking at effective Program Management to play a critical role in bridging the gap between formulation and effective execution of strategy. To date, however, recognition of the importance of Program Management or adoption of Program Management practices is definitely lagging behind Project and Portfolio Management even in project management mature organizations.

[...] Program Management facilitates optimization of costs, resources and staffing, integrates and resolves inter project dependencies and deliverables, and ensures achievement of expected benefits.

She offers the following steps for success:

1: Identify initiatives best defined as programs
2: Define target benefits
3: Develop alternative approaches to delivering desired results
4: Analyze and select best options for implementation and identify component projects
5: Undertake stakeholder analysis and establish governance structure
6: Engage the Program Manager

There are lots of definitions about what project management is:

"Project management is the application of knowledge, skills, tools and techniques to project activities to meet the project requirements." PMBOK, 4th Edition

"Project management is the discipline of planning, organizing, and managing resources to bring about the successful completion of specific project goals and objectives." Wikipedia

Yet a writer at ProjectSmart pauses to ask what project management is not:

1. An activity where you create your plan and watch it play out perfectly until the Project Complete milestone.
2. Just PMBOK Tools \& Techniques
3. Loading up projects and people with meaningless process that hinders the work
4. Being in control: Unless by control you mean being inside quality control limits
5. Just schedule tracking

Would you add anything to the list of what project management is not?

Josh Nankivel of The PM Student has written a piece for PM World Today on "Starting Your Project Management Career." (You may remember him as one of the bloggers who interviewed our CEO when he published his first book.) He mentions that project newbies, technical gurus and people managers can often struggle with making the transition to project management, and he gives advice on hard and soft skills that come in handy, resources for building knowledge, and how to choose a mentor.

What advice would you give to someone starting out on what has helped you the most?

Project Smart has a list of tips on how to restart your projects now that the recession is drawing to a close. They all boil down to reassessment: Don't expect to have the same objectives, budget, resources, etc. now that you did when the project was first conceived. Taking stock of the new situations will go a long way toward project success.

In addition, you will need to decide which projects have the best chance of success and which ones are too risky. This involves using time data to analyze and predict profitability, managing resources effectively, and keeping track of project status in order to head off disasters.

PMOs have it hard. Our CEO addressed this when he wrote them a recession survival guide. CIO writer Adam Bookman agrees, and his latest article highlights three key "pitfalls" that PMO risk falling into:

1. The One-Way Street

Give to get. Return value to your sources. Remember, you have two sets of "customers" — executive management and the project teams.

2. One Size Does Not Fit All

Moderate PMO requirements according to the project's risk and the team's maturity.

3. How Am I Doing?

Cultivate relationships along with rules. Both will benefit. Know how the PMO is valued by its customers.

Does your PMO struggle with these issues?

Towards the start of the year, we blogged about the Project Times list of the Top PM Trends for 2010. Now Project Smart has compiled their own list, "More 2010 Project Management Trends."

Drumroll, please:

• Enterprises Continue to Look for Efficiencies in Process and Technology
• Agile and Lean Processes are Overtaking Waterfall
• PMs are Becoming Independent Consultants
• Virtual and Independent Teams Will Be More Prevalent
• Social Media Will Become a Norm
• Project Manager and Business Analyst Roles are Converging

The overwhelming consensus is that technology is more significant than ever before in the business world. People are finding that they need to automate processes for increased efficiency in addition to transparency, visibility and communication. Agile is also taking over where waterfall software development processes used to reign.

How will these changes affect your organization? Have they already?

Project Times has published an article by Elizabeth Larson on the competition between the two types of software development processes, agile and waterfall.

I think people like a good fight. Certainly the media seems to, as is evident in the world of politics, sports, and entertainment to name a few. In the world of business analysis the current fight seems to pit Agile methods against the Waterfall approach. For the next several blogs we’ll have a Scrum vs. Waterfall match. In corner #1, representing the Agile methods, we have the Scrum framework. In corner #2, representing Waterfall, we have the “traditionalists.”

Larson awards both rounds to agile. Why? It allows the team to adjust estimates and deadlines based on real feedback and progress, and it makes things "easy and practical." Agile is clearly gaining ground in the software development and project management worlds, and it shows no signs of stopping.

--

Related stories:

E-Commerce Times: How to Create an Agile PMO

gantthead.com: The Agile PMO Role

Projects@Work: Agile Rising

Lisa Anderson at Project Smart has provided her ideas on the top 3 causes of project failure:

1. Lack of a Clearly Designated Project Leader
2. Lack of Clear Expectations and Goals
3. Communication Challenges

The common thread here seems to be communication and clarity. Projects cannot succeed unless everyone knows who is in charge, what the expectations and goals are, and what they are supposed to be doing. I would add 'Lack of Visibility' to the list, because not knowing which resources are available, how much work has been completed and how much remains, and how much time and money has been spent on the project is a recipe for disaster as well.

--

Related stories:

Project Smart: Avoiding Project Failure: It's Not Rocket Science

MindTools: Why Do Projects Fail?

Journyx Project Management Blog: The Human Element

Processes are the backbone of most organizational success. Get the right one in place and see increased efficiency in all that you do. Implement the wrong one, or none at all, and there is chaos. PM World Today published a guide called "A Blueprint for Successful Organizational Process Change" that offers suggestions on how to facilitate change management when obstacles (e.g. employee resistance) stand in the way.

Think back to a time when you observed a problem in your organization and developed a more attractive solution. Believing it was the most efficient and thoughtful approach to resolving a problem plaguing the organization, you began to immediately roll out the change. Surprisingly, the change was met with questions and team members seemed unwilling to adopt the new process. Does this sound familiar?

The author recommends the following steps:

1. Identifying Initial Support During Inception
2. Pilot Programs to Involve Key Team Members
3. Organizational Communication and Implementation

CRM News recently ran a story from Journyx about how important it is to be sensitive to the culture when setting up new processes. Some companies make the mistake of forcing people to give up their processes and adopt entirely new systems that are unfamiliar. There is a way to introduce new, more effective processes while still retaining what works and what people are comfortable with.