Rules Should Not Apply

Some organizational rules are critically important to keeping people safe from harm. Organizational leaders should ensure these rules are always followed. Other organizational rules exist to help staff know what to expect and to keep operations running smoothly. Making project teams working on critical change initiatives follow these rules can often do more harm than good.

Publication Date:  30 January 2024

One of the most common mistakes leaders make when trying to transform their organizations is tying their project team’s hands by forcing them to follow the same rules as everyone else in the organization. Rules exist to constrain people’s actions and maintain the status quo. Thus, forcing a project team to follow the same rules as everyone else in an organization inhibits the team’s ability to transform the organization and sends the message to the rest of the organization’s staff that the project team’s work and objectives are not all that important.

There are two primary reasons for organizations to have rules. The first reason is to keep staff from performing actions that could cause harm to themselves or others. Many rules of this type are codified in national and local regulations and include things like following proper protocols when performing hazardous tasks, wearing protective equipment in dangerous environments, and properly disposing of hazardous materials.

The second reason organizations have rules is to help staff know what to expect and ensure operations run smoothly. Rules of this type are typically not enforced by anyone outside the organization and often cover things like the proper protocols for getting items approved and timelines for submitting requests and getting activities completed.

Organizations need rules of both of the types discussed above to be successful. However, the first type of rules, those that keep people from being harmed, are much more important than the second type of rules. In fact, rules of the first type are so important that leaders of organizations should never allow them to be broken by anyone, regardless of the reason.

Rules of the second type are much less important than rules of the first type for the simple reason that breaking rules of the second type should not result in anyone being seriously harmed, unlike what can happen when rules of the first type are broken. Breaking rules of the second type might result in people being inconvenienced or slightly annoyed, but no more significant harm than this should occur as a result of not following them.

While organizational leaders should never allow rules of the first type to be broken by anyone, for any reason, they should allow rules of the second type to be broken by project teams working on crucial organizational change initiatives.

There are two reasons project teams should be allowed to break the second type of organizational rules. The first reason is that such rules often get in the way of project teams successfully accomplishing important change initiatives. Rules about such things as chains of command for getting things approved, request processes, timelines for actions being completed, etc. often do nothing more than slow down project teams and hinder their ability to make timely and meaningful changes to an organization. Leaders who force project teams working on important change initiatives to follow such rules endanger the success of important projects.

The second reason project teams working on important change initiatives should not have to follow the second type of rules is that allowing such teams to break these rules sends a message to the organization about the importance of such projects. By allowing project teams to break rules of the second type, leaders are in essence telling the entire staff of the organization that the project the team is working on is more important than how the organization typically conducts business. This powerful message can greatly help critical change initiatives succeed by dramatically illustrating to all staff and stakeholders the level of importance of the project team’s work.

Some rules are more important than others. Rules designed to keep people from being seriously harmed are critically important and leaders should never let such rules be broken. Rules designed to make sure staff and stakeholders know what to expect and to help operations run smoothly are much less important, and leaders who force project teams working on critical change initiatives to follow such rules decrease the chances such initiatives will succeed and demonstrate to staff and stakeholders that such initiatives are of minimal importance.

The Importance of Traceability

Many software development projects waste time and resources creating system functionality end-users do not want or need while failing to deliver things end-users have specifically requested. Often poor traceability practices are to blame for these failures.

Publication Date:  25 January 2024

Software development projects often fail to deliver everything end-users want and need. They also often waste time and resources creating unrequired items. Following good traceability practices can keep both of these things from happening.

Traceability refers to the practice of ensuring everything that is built as part of a software development effort can be directly “traced” to something requested by end-users. As such, good traceability begins with good requirements gathering.

Requirements gathering is the first step of most software development projects. This process entails members of the development team interviewing end-users about what they need the system to do and documenting these needs in some form of functional requirements.

A functional requirement is simply a statement about some function end users need a system to perform. For example, a set of end-users might need to be able to capture the first and last names of customers who have purchased a product. The functional requirement for this would be something like “The system shall allow users to capture the first and last names of customers who purchase a product.”

Functional requirements simply state what a system needs to do to meet the needs of end users. They do not say anything about how the system will meet this need. This is defined by technical requirements.

Technical requirements define how a system will meet the end user needs specified in functional requirements. The technical requirements for the example of capturing the first and last names of customers might be something like the following:

The system shall provide a 15-character text input field for users to type a customer’s first name
The system shall provide a 50-character text input field for users to type a customer’s last name

These two technical requirements spell out in detail what will be built to meet the end-user needs stated in the associated functional requirement.

Ideally, every functional requirement should be traceable to at least one technical requirement, and every technical requirement should be traceable to at least one functional requirement. Any requirement, whether functional or technical, that does not achieve this is said to be an orphan. An orphan functional requirement is one that does not have any associated technical requirements. Orphan functional requirements represent user needs that the system will not fulfill. An orphan technical requirement is one that is not associated with any functional requirement. Orphan technical requirements represent system functionality that users do not need or want.

To ensure software development efforts meet all of the needs of end-users and do not waste time and resources building things that are not required, end-users should review and formally approve all functional and technical requirements before the associated features are developed. Part of this review should focus on ensuring full traceability between the two sets of requirements. Development teams can facilitate this review by specifying which technical requirements trace to which functional requirements and vice versa.

Software development projects that do not follow good traceability practices run the very real risk of creating systems that do not meet all of the needs of end-users and wasting time and resources developing system features that users do not want. Given how easy it is to ensure full traceability between functional and technical requirements, there really is no excuse for this to happen.

How and When You Communicate Matters

Most organizations understand that communication can make or break a project. Nonetheless, few organizations actually effectively communicate with staff and stakeholders about key initiatives. In particular, many organizations wait too long to communicate with staff and stakeholders and use horribly ineffective channels when they finally do communicate.

Publication Date:  24 January 2024

Communication is one of the most critical aspects of organizational change management. Good communication can significantly increase staff and stakeholder support for a project, leading to increased adoption of changes and higher project returns. Bad communication can destroy staff and stakeholder trust and support and lead to project failure.

While most organizations understand the important role communication plays in the success of projects, many organizations fail to effectively communicate with staff and stakeholders.

One of the most common mistakes organizations make when communicating with staff and stakeholders about projects is waiting to discuss essential topics until everything is known and finalized. Many organizations are hesitant to communicate tentative information because they fear something might change, requiring them to revise communications and resulting in staff and stakeholders losing trust and confidence in the project. But in reality, this very rarely happens.

Most staff and stakeholders understand that things can change as a project progresses and therefore do not lose trust and confidence in a project due to being told tentative information that later changes. However, not receiving any communications about important topics often does lead staff and stakeholders to worry. Humans typically deal poorly with a lack of information, and not hearing anything about an important issue often makes people worry more than hearing news they do not like. Therefore it is typically much better to communicate tentative project information to staff and stakeholders as soon as possible and revise the information later if needed than to wait to share information until everything about the subject is known and finalized.

Another common mistake organizations make when communicating with staff and stakeholders about projects is relying on existing communication channels to disseminate information. Many organizations have established communication channels like weekly electronic newsletters and internal websites that are routinely used to communicate information to staff and stakeholders. Utilizing these channels to share information about critical internal projects is often very tempting. However, it is almost always a horrible idea to do so.

There are two reasons why organizations should refrain from using existing communication channels to provide information about important projects to staff and stakeholders. The first reason is that existing organizational communication channels are typically abysmal at actually communicating information. Because they are used to communicate with people in so many different roles, most internal websites and electronic newsletters contain large amounts of information that is not relevant to specific readers. This makes it hard for readers to find information they are interested in, which in most cases leads staff and stakeholders to simply not engage with these communication channels at all. Most organizations’ internal websites are rarely accessed, and most electronic newsletters are deleted without being opened.

The second reason organizations should refrain from using existing organizational communication channels for sharing information about critical projects is that doing so makes projects appear less important than they often are. Existing organizational communication channels are typically established to communicate routine organizational information to staff. Therefore, using these communication channels to share information about important internal projects creates the impression that the projects are nothing different than business as usual and are no more important than everything else going on in the organization. This can significantly undermine the perceived importance of critical initiatives and lead to decreased staff support and adoption of required business changes.

Instead of relying on existing communication channels to communicate information about important projects, organizations should create new and novel communication pathways that stand out from the drone of everyday business communications. This will help ensure project information is effectively communicated to staff and stakeholders and increase a project’s perceived importance. In addition, organizations should not hesitate to share tentative information with staff and stakeholders. Even if it is tentative, communicating information early decreases worry and helps increase support for a project.

It is So Shiny! I Need to Have It!

It seems like every few years, some new must-have process or piece of technology sweeps through industries. When this happens, it can be very difficult for leaders of organizations to resist the urge to jump on the bandwagon and adopt the newest thing, even if doing so might be in their organization’s best interest.

Publication Date:  24 January 2024

Have you ever noticed how every few years some new process or piece of technology sweeps through your industry and all of a sudden everyone is starting to use it? I have, and I have also noticed how hard it can sometimes be for the leaders of organizations to resist the urge to go along with the mob and switch to the newest, flashiest, trendiest thing – even when it seems like there might be better ways for the organization to use its time, money, and other resources.

One of the reasons it can be so hard for leaders of organizations to resist the urge to implement the “newest thing” is that there is safety in going along with what everyone else in your industry is doing, and there is real danger in going a different direction. A leader who goes along with industry trends can much more easily justify their actions should something go wrong than a leader who goes against trends, even if there are compelling reasons for an organization to do something different than its competitors. If something goes wrong, the leader who goes with an industry trend can always justify their actions by explaining how they made the prudent decision to follow industry best practices of the time. The leader who goes against an industry trend will likely face the uncomfortable situation of explaining why they thought they knew better than all their competitors.

While following industry trends is often the safest road the leader of an organization can take, it is not always the one that will actually lead the organization to the best outcome. Luckily, there are a few questions a leader can ask that will help them determine if they should follow an industry trend or not.

The first such question a leader should ask is whether or not the new thing will help the organization solve an issue or challenge the organization was actively trying to address before knowing about the new process or technology. If it does, then the organization should consider adopting it. However, if the latest thing does not address such an existing known issue or challenge, it might be in the organization’s best interest to spend its time and resources elsewhere.

There are some instances in which it might make sense for an organization to adopt a new process or technology even when it will not help the organization address a known issue or challenge. This is the case, for example, if not adopting the new process or technology will cause the organization to fall behind its competitors in an identifiable way. The key here is that the organization needs to be able to specify the exact way it will fall behind if it does not implement the newest thing. It should not be enough just to have a vague feeling or notion that not doing something will cause the organization to lag behind its competitors. A leader should be able to easily say, “If we do not implement this new process/technology, then our competitors will be able to do (x), and we will not.”

While identifying how a new process or technology will address an existing issue/challenge or help an organization keep up with its competitors indicates that a leader should consider adopting the process or technology, it alone is not enough to definitively determine whether or not adopting the newest thing is in the organization’s best interest. One more question needs to be asked; namely, is this the best way for my organization to address this issue/challenge or keep up with its competitors?

Just because the newest thing can help an organization address a known issue or challenge, or help the organization keep up with its competitors, it does not mean it is the best way for the organization to do this. There might be other ways that will better fit the need. Perhaps there are different options that will help the organization even more. Or maybe there are options that will work just as well, but will be cheaper or easier to implement.

It can be hard for leaders of organizations to resist the urge to jump on the latest trend in their industry, but there are times when it makes sense to do so. Specifically, an organization might be better off skipping adoption of the latest and greatest thing if it does not address a known issue or challenge, is not required to keep up with competitors in a known and easily specified way, or is not the best way for the organization to do either.

The Most Important Aspect of Change Management

It can take a lot of time and effort to complete all of the work required by many formal change management methodologies. If an organization has the resources to complete all of this work, it is often very beneficial to do so. However, if an organization does not have the resources to do this much work, significant gains can still be made by focusing solely on the most important aspect of change management.

Publication Date:  22 January 2024

The use of formal organizational change management methodologies has increased dramatically in recent years. Many organizations that just a few years ago were barely familiar with the concept of change management now employ some formalized form of it on most, if not all, of their projects – and a lot of these organizations have seen the use of formalized change management methodologies result in significant improvements in staff and stakeholder support for projects, which in turn has often resulted in improved project returns.

While there is little doubt that using formal change management methodologies can improve staff and stakeholder support for projects, the amount of work required to employ such methodologies fully can sometimes seem overwhelming, and this sometimes keeps organizations from trying change management at all.

Many formal change management methodologies require organizations to spend a significant amount of time completing assessments and creating change management sub-plans. A common place for formal change management methodologies to start is with some sort of assessment of an organization’s readiness for change. This assessment often requires a significant number of staff and stakeholder interviews and surveys. The information gathered from this assessment is then typically used to create several different change management sub-plans – typically including at least a communication plan, a training plan, a resistance management plan, a management coaching plan, and a sustainment plan. These sub-plans then guide the rest of the project’s change management effort.

It can take quite a bit of time and effort to do all of the work described above. If an organization has the resources to do all this work, it is typically well worth it to do so. However, some organizations simply do not have enough resources to get it all done. Luckily, an organization does not need to do all the work associated with formalized change management methodologies to achieve many of the benefits change management can provide.

The most essential part of change management is creating a desire for change in staff and stakeholders, and organizations that have limited change management resources will be best served by focusing their efforts here.

The reason creating desire for change is so important is that the success of all other aspects of change management is fundamentally tied to it. Staff and stakeholders who desire to see an organizational change take place are less likely to resist the change, will be more engaged in learning about and training for the change, and will work harder to sustain the change than staff who do not desire the change. Therefore, an organization that focuses its change management efforts on creating desire for a proposed change also significantly helps itself be successful in the other main areas of change management.

No other area of change management has nearly as much impact on the success of a project as that of creating desire for change. No amount of resistance management, training, or sustainment activities can overcome a lack of desire for change. Conversely, a sincere desire for change significantly decreases resistance, increases sustainment, and goes a long way toward overcoming less-than-perfect training. Simply put, people who desire to change will, and people who do not desire to change will not.

All aspects of change management are important, but some are much more important than others. Creating desire for change is far and away the most important part of change management. If an organization has the time and resources to do everything entailed in formal change management methodologies, it will most likely benefit from doing so. If not, focusing on creating desire in staff and stakeholders for proposed changes will by itself dramatically increase the chances of success.