Methodology

A development project begins because of a need to fix a problem. In general terms, the problem exists in the business because there is something occurring that either takes too much time or does not create the desired outcome. In other words, there is a disconnect between the way things are expected to work and the way things actually work. This is known as the gap, but for simplicity within this text, I will refer to it as the “problem.”

There are often many meetings that occur in which employees talk (or complain) about their frustrations within their job functions or about the company. These frustrations tend to build up, particularly if the company is growing, has high turnover, or is undergoing reorganization. When these frustrations build up to the point that management is constantly being pulled into meetings to solve them, it becomes a tipping point for the organization that needs to be addressed.

This tipping point of awareness is the realization that if multiple people have the same frustrations that are repeatedly expressed, then the problem must be widespread, and it would be beneficial to figure out a solution. That tipping point obviously needs to occur before any action is taken to solve it. If there is a large divide between executives, management, and employees, then it is possible that this tipping point of awareness would never even occur. However, when awareness does occur, and when the decision is made to fix the problem, the correct department heads need to be involved to buy into the decision.

For a project that needs the resources and time of technical development, company leaders should begin by having a preliminary discussion to obtain approval from the appropriate heads of operations, finance, and development.

Communication

Communication is key—not just for the complete success of a project, but for the project to even commence.

Lack of communication often results in teams being unaware of issues such as:

• Other teams that have similar struggles and are working on similar objectives.
• Other teams that have different, even conflicting, objectives.
• Conflicts of priority of workload items among teams.
• Overlapping job duties among teams.
• Absence of job duties within the company.

For an operational team that is generally not involved with technical development—such as supply chain, customer service, or field service—they may not be aware that the development team is already working on projects that could be used (or repurposed) as a basis to achieve its operational goals and fix the problem.

In very large companies that have multiple operational teams and departments, it is possible that the teams report to different business units, and therefore have different metrics and goals they are supposed to meet. In this instance, the teams could be working on solutions to their own frustrations that completely contradict the other team’s goals.

For example, take a company that has a Contracts department and an Order Entry department. The Contracts department needs to ensure that they have a shared system so all the members of their team can access contracts and see changes that have been tracked with amendments, without having to open each document. The Contracts lead begins to work on a project to implement a web-based tool where contracts can be saved, and the amendments show as edits to one document.

Similarly, the Order Entry department needs to access contract information so that they can enter the orders with the correct pricing as it exists on the contract. The Order Entry lead determines they need a place to store contract pricing so that they are able to pull it onto their orders automatically. In this example, it seems like an easy solution is to have these two teams partner together so that the Order Entry team can utilize the pricing from the web-based contracts system. However, imagine that the company overall has around 200,000 employees, and therefore each of these teams consists of thousands of people. And further, in the organizational hierarchy, the Contracts team reports to Finance, and the Order Entry team reports to Customer Service. It becomes clear how the two teams can work on something so similar, yet never connect.

Conversely, there may be an overlap between operational teams. It is possible for two operational teams to process the same information in different ways.

Duplication of work is a shame, but it is possible for two teams to believe the other performs a certain job when no one is performing the work at all. This happens for work that should be confirmed or reviewed. A team might assume the information they receive must be correct, because they do not understand the process that brings the information to them. They then will process the work without any confirmation, and if something seems incorrect, they assume the confirmation of information happened before it came to them.

Team leaders—whether supervisors, managers, or business unit heads—should always have a cadence of communication to share ideas, best practices, and problems.

In a case when a problem has hit the tipping point and there are thoughts of a new project to solve the problem, a preliminary discussion should happen among the team and company leaders. This allows the teams to achieve awareness, alignment, and agreement before any work begins.[1]

The simple fact that communication is present can be the difference between a successful project and one that crashes and burns. When communication is absent in an organization, assumptions are made about workload and projects that cause teams to be misaligned on their work and goals. This type of atmosphere leads to resentment and employees who are not vested in the outcome of their work and projects.[2]

The following sections examine specific aspects that are the foundations of transparent communication.

Awareness

Teams under different leadership, and reporting to different business units, are most likely not keyed in and aware that a problem exists. In fact, one team could have already solved the problem that another team faces. Without awareness among teams, the company is not able to best leverage ideas, processes, and resources that already exist.

A communication cadence and a conversation structured around the identified process problem allows for all teams to become aware of the issue. This could lead to presenting alternate quick-win solutions without the need to engage on a project.

Tactically, a weekly team update that is distributed both to management and peer team leaders is a simple solution that can be easily implemented to help awareness.

Alignment

Different teams have different perspectives. By becoming aware of an issue, teams will naturally discuss, from their perspective, how they would solve the issue, which will allow for a broader discussion to take place so that the teams agree upon the general issue.

During their discussion, they may realize that other teams are affected, at which point they would bring in the heads of those additional teams. The teams may even realize that fixing a problem on one team could relieve pressure on another team.

For instance, implementing a portal to allow customers to enter their own orders could relieve pressure on an order-entry team as well as on an invoicing team, if they are able to leverage that same portal for billing.

Additionally, alignment between the company’s goals and any team projects is pertinent to business success. Oftentimes, the business-development side of the company could implement new strategies, but if there is not transparent communication to ensure the operational side of the company is aligned, then the hours and work incurred will be wasted effort.

Agreement

Once aligned, the teams may have different ideas on how the issue can be solved; however, at least they will all agree that there is an issue that needs a resolution. Achieving agreement that the problem exists at this point is pertinent to allow for a project to begin so that the business process can be adjusted.

A point of agreement can rarely come to fruition unless there is awareness among teams, so it is a crucial first step to develop that communication transparency among teams. When teams are comfortable with each other and understand each other’s goals and struggles, they are able to work together toward a shared solution. Since it is easiest to be close with those that we communicate with the most, achieving comfort among teams can be as easy as ensuring the team leads have a conversation with each other once per week.

The 80/20 principle

The 80/20 principle, also known as Pareto’s law, is perhaps one of the most powerful rules of thumb to apply in business processes. The 80/20 principle states that 80 percent of results are from 20 percent of causes.[3]  Within a business, it very simply breaks down to mean that, generally, 20 percent of the effort of a team results in 80 percent of the output. So conversely, 80 percent of their time is only resulting in 20 percent of the output. So if the team’s efforts are focused on reducing the larger piece of the pie (80 percent of the work) by increasing efficiencies, menial tasks can be reduced or eliminated.

Example of Pareto’s law

A familiar reference here is wasted time in a meeting. In about 80 percent of a meeting, you are discussing “what ifs” and hypothetical situations, but in the last 20 percent of the meeting, there is movement to where solutions are proposed, and actions and accountability take place. To prevent the 80 percent of the work that’s less productive, ensure that management understands Pareto’s law so they can be proactive to prevent wasted time.

For example, those theoretical “what if” situations that surface in meetings are often the reason for not implementing a new procedure or business process that would then allow for business operations to work smoother. Teams often do not take the time to set aside those “what ifs” to understand the bulk of the standard work. It is true that those theoretical situations may occur, but the team only needs to create an exception process for those situations. Since the exceptions are part of the minority of the problem, it is best to set them aside and create the exception processes for them after the majority of the problem is solved. The exceptions can be set aside in the “parking lot.”

The parking lot

Of the many personalities encountered in a workplace, there will surely be a few people who are stuck on outlying scenarios that don’t directly relate to the scope of a process. For the project to be inclusive and keep momentum and support, it is important for everyone to feel that their ideas are acknowledged and addressed.

A common way to handle either the seemingly out-of-scope issues or the 80/20 principle items is to use a “parking lot” during meetings and when outlining the process. The parking lot is a metaphor for all the items that people are concerned about, but that are also outside of the most productive work, according to the 80/20 rule, or are outside of the scope of the project.

The parking lot is simply a list that is kept that records all the what ifs and outliers. This ensures that everyone’s comments are heard and recognized as being valid but are not acted on immediately so that meetings are not sidelined to deal with something that is an exception.

While the project is in process, the items from the parking lot are reviewed to see if they can be addressed. Any items that remain in the parking lot are to be closed out at the end of the project.

Key people and departments

When a problem begins to shape into a project, it is impossible to know initially which people and departments could be affected.

During preliminary conversations, if you realize that other people or teams should be involved in making a problem into a project, then another conversation should be scheduled that includes the heads of the other teams. Awareness, alignment, and agreement should take place again with the additional team members.

Additional meetings can be frustrating and feel like a waste of time, particularly for higher-level management; however, in these instances, the mindset should be adopted that planning and preparation support proper execution. Various sources report that time spent planning saves approximately 3–10 times as much effort during the execution phase.[4] While it may seem redundant and cumbersome to involve new people in these preliminary planning stages, imagine the amount of time it would save if the new people said they already had a similar project in process, or if they were privy to information about future company reorganization that may affect the project. Knowledge like this would save hundreds of hours that would otherwise be spent creating and developing a project that would eventually be null and void.

During the initial meetings, there may be teams who feel they do not need to be involved in the project directly but instead just need to receive milestone reports and progress updates. It is acceptable and encouraged to do that, and these people will become stakeholders in the project. This is acceptable as long as these people genuinely do not need to be involved in the decision-making process. However, if not including anyone only causes additional meetings to occur later in order to bring them up to speed due to disagreements or interjections, then that person needs to be involved in the project directly. Again, time spent planning reduces time spent in execution.

The project team

The Project Management Institute is the leading resource on complete and detailed best practices for project management, and they even publish the Project Management Body of Knowledge, also known as the PMBOK. This is an extremely comprehensive guide to creating and executing a successful project, which you can consult for any project-specific questions or concerns.

At this point the project is preliminary, so each key person should have enough general knowledge of their department operations or know the appropriate point people that they can leverage as subject matter experts for any questions. The selected key people need to be committed to the project by agreeing to attend and engage in related meetings. These key people become the business project team.[5]

A list of the stakeholders and sponsors is created. The stakeholders are the people who have a vested interest in the project.[6] For the purposes of this text, and to put the project team into context, the following section provides brief descriptions of the key people on the project.

Sponsor

The sponsor leads the general direction of the project as the direct line between the project and the executive team. Often the sponsor is a member of the executive team, so they understand the company and management goals as well as the project. The sponsor helps with any misunderstandings and provides clarification when needed. The project sponsor is essentially the person who is committed to owning the project and ensuring it comes to completion.[7]

Project manager

The project manager is the person directly leading the project and is responsible for communicating updates about the project and keeping the project team on schedule. They will ensure the project has the resources and correct people, and they will be able to count on their sponsor if they have any issues accomplishing that.

Other project team members

The other members of the project team consist of the previously identified key people who have a vested interest in the project and want to help bring the project to life.

Other stakeholders

Everyone on the project team is a stakeholder, but there are also interested people, described previously, who are not involved in every meeting, but would rather be kept in the loop via updates. As the project continues, these stakeholders may vary as people’s positions change, or as the project’s scope becomes more defined, making it clearer who else has an interest in the project.