Non-Measurable Organizational Value is the concept of corporate benefit being derived from a project that is inherently non-measurable. To some degree all value is difficult if not impossible to measure accurately except in extreme circumstance. Organizations are complex entities and any project or process is just one of many projects or processes that all contribute in some way to value.

Let us look at a quick example of a difficult to measure project. Project X at ABC Corporation (they give all of their projects letter-names for some reason) is a project to add four important new features to one of the company’s software products. The project runs its course and is estimated to have cost the company almost exactly $100K to complete. The new features are now available in the product which is available to existing customers as a free upgrade and are included in the shipping product to all new customers. Now we must determine the Organizational Value or OV of these new features.

These new features are designed to derive their organizational value from several planned sources. The first source is through “feature marketing“. In this capacity we are left attempting to derive, generally, through collected sales data both before and after project completion what the change in sales is because of the new, added feature. This has to be balanced against any changes in sales or marketing, changing market pressures, increased product maturity, changes in competing products, etc. Even asking customers to voluntarily report on this data can be very misleading in the best of circumstances.

The second source of derived organizational value is through customer retention. This is far more difficult to calculate than the somewhat ephemeral marketing and sales aspect of the first source. To some degree you can calculate the number or percentage of customers who decide to go through the upgrade process if they are downloading the update from ABC’s web site. But you are still left estimating what percentage of customers did the upgrade simply because they felt that they should use the latest version, who wanted to get the features but would not have switched products to get them and which customers would actually have taken the effort to switch to another product to acquire those features.

This approach does not consider the market affects that ABC’s new features have had on its competitors. In some cases by supplying in-demand new features ABC may have driven the market forward forcing competitors to include those same features, but it may also have done research and development that now its competitors can copy at lower cost. Or perhaps it has implemented features so costly or specialized in nature that competing products avoid implementing those same features simply because they are already available on the market. Estimating ABC’s market effect is very difficult if not impossible.

The third source of revenue is difficult to calculate as well. This third source is through market preparation. By this I mean that two of these four features implemented by ABC Company are building blocks that are expected to lead into another project that will provide a number of really incredible and difficult to produce features in another year. A certain amount of planning and framework design was done during this project in order to prepare for the following project. A few hundred hours of manpower were put into this robust framework that would have been excessive for just the current features but will allow future features to be added in more easily. This technology investment will not see dividends until other projects, seeking their own organizational value calculations, are layered on top of it.

In this example of ABC’s Project X we see that this project was based mostly upon Non-Measurable Organizational Value. Some of these value sources could be examined and an estimate of OV could be extracted. But this is, at best, guesstimation and the organization would need a very carefully managed process to keep this type of guesstimating consistent and fair between projects. But there are other NMOV concepts that we should also address.

One type of NMOV is employee morale and the related “development velocity.” Employees, especially technical workers, are highly affected by their work environments and generally desire to be allowed to produce good products. Developers and analysts will often state that the value and quality of their work is a driving factor in their level of job and career satisfaction. A company with high morale, satisfaction and happiness will generally get better products and it will get them out the door faster. Teams are more likely to gel. Sick time goes down. Communications go up. A project will not often be undertaken purely out of concern for employee morale but a feature, a methodology, a technology or a technique might be chosen for just this reason. A project might be written in Java instead of C++ just to keep a team more interested in their work, for example.

Now we can attempt to measure employee morale in several ways but we have two main arguments preventing us from doing any meaningful measurement. The first is that there is no good means of measuring an increase in morale based on project decisions. Finding single points of morale boost or morale decrease may be possible but determining overall morale deltas caused by a specific project separate from the overall organization culture is simply unreasonable. The second argument, against being able to measure the OV, is that even once morale change is estimated it is then not possible to determine the degree of effect that this will have against the short term or long term organizational bottom line. And, of course, we must consider the morale bolstering affect of an organization being willing to sponsor projects for the purpose of or, at least, with consideration towards employee happiness.

But this is not to say that employee morale has no value. Certainly it does. I believe that it is an important factor in organizational health. A very important factor indeed.

Any project looking to determine its own value cannot truly do so without considering the implications of non-measurable organizational value. But to what extent should these factors be considered? To this, I believe, there is no simply answer. In an extremely large enterprise where many years of metrics could be collected and careful research into marketing, market pressures, competition, morale, productive velocity and more can be collected and calculated, over a very large system of hundreds of thousands of employees, I believe that we should be able to see reasonably consistent trends that will lend themselves to reducing NMOV factors into estimable organizational value. However even in this circumstance these calculations will have to be done at a very high level of abstraction with a significant amount of organizational research ongoing at all times. And results, unlike OV from specific projects, are most likely to only have a good degree of confidence when undertaken as organizational directives and initiatives and not on a project by project basis.

Large enterprise organizations, those with tens or hundreds of thousands of employees, are often caught by their own bulk and momentum and find that many NMOV factors do not exist for them in the same manner than they exist for small companies. At the one extreme a behemoth manufacturing company with a half million employees will find enacting organization wide morale or velocity initiatives to be difficult to implement, difficult to measure and that the effects are minimal as the momentum of the firm keeps these changes from trickling down to the majority of the workforce without being watered down by the established corporate hierarchy until even the attempt at change is seen as a waste of effort. Large enterprises often settle into a relatively stable state of morale with only truly significant events having a serious or long lasting effect.

Small companies, especially those under five hundred employees, can find a much higher value in NMOV, in my opinion. Small companies gain some of their greatest advantages through the leverage of NMOV. In a tiny company of twenty people one great project could invigorate the entire company for potentially years. Culture and attitudes can change almost instantly and truly great velocities can be achieved and maintained. Smaller companies need to be more attuned to the NMOV factor than their large counterparts. It can be both an advantage and a disadvantage. Small companies do not have the luxury of the employee scale buffer (read: organizational momentum) to keep morale busting events from dragging a company down quickly.

Some larger companies have become famous for managing to keep morale and culture at the forefront of their priority list with exceptional results. Notably Microsoft and Google have become poster-children for great corporate culture even in large firms. And both have become well known for consistently delivering strong technical products, moving the market forward, breaking new ground and keeping employees very happy. Both are also known for investing heavily in research and development which are often incorrectly thought to be NMOV activities but, over time, R&D activities have a reasonable level of estimable value.

NMOV cannot be the sole driver of organizational projects but it should not be discounted. NMOV should be considered even if, at the very least, only from the aspect of attempting to mitigate negative NMOV behaviour or project choices. To some extent, though, I believe that NMOV should be estimated through soft calculations and guesstimation to be accounted for within organizational project portfolio planning as well as corporate culture fostering activities.

Perhaps NMOV, given the potential value that it can add to an organization, should be considered not to be non-measurable but to be immeasurable.

Marchewka further breaks down the term MOV and says that it must implicitly include the following: be measurable, provide value to the organization, be agreed upon and be verifiable. Let’s look at each of these.

Measurability is obvious yet extremely difficult. Many benefits of IT projects are “soft” and inherently unmeasurable. For example, a project that makes employees more happy cannot be measured as it is never possible to determine how much happiness is the result of any one project and how much other organizational efficiencies can be attributed to employee happiness and morale. And yet we almost all agree that happy employees work better, are more loyal, cost less and interact better with each other.

The idea behind measurability is that no project decisions should be made without a consideration towards how they will affect the project’s MOV. If a new feature is being considered, for example, then that feature should be compared against the MOV. If the feature will not increase the MOV then it should not be included. A relatively straightforward concept, but it basically states that only measurable value should be considered. This is not always intuitive.

Project Management by MOV should provide value to the organization. This is the underpinning of the MOV concept and is analogous to the concept of ROI. ROI, however, is a measurement of the difference between expenditure and the expect value to the organization. MOV does not seem to take into account the cost of its own provisioning and only looks and the measurable business value after project completion while ROI takes into account the cost of providing the MOV as well as having the potential to consider the non-measurable organizational value which may be the driving force or a project.

A project MOV must be agreed upon. Marchewka states that all project stakeholders should agree upon the MOV of a project before the project starts. This requirement includes making business stakeholders as well as technology stakeholders, such as analysts and developers, agree to the MOV before a project begins as a later measurement of project success. This is a difficult task as it is in one group of stakeholders’ interest to make the MOV high while it is in the interest of the technology stakeholders to make it low. This is especially difficult as it benefits the business side to trick or take advantage of the lack of business acumen from the technology side and requires the technologist to allow themselves to be judges of something that they neither understand nor ultimately control.

Verifiability of the MOV is key. Since the project’s MOV is measurable by definition it must then be verifiable. After the project has been completed the MOV is to be verified to determine if the project was successful or if it was not. However, Marchewka does not seem to address the issues of ongoing organizational value. A typical IT project will deliver negative value up front and will increase in value over time and then, eventually, decrease in value until it is replaced. True MOV would not be verifiable until the end of its lifespan.

For example, since code from IBM’s System/360 project from 1964 is still widely in use one would assume that IBM has not yet been able to determine the final MOV for that project. If their initial estimates had been extremely accurate and had taken into account a lifespan that might even top fifty years then the MOV would not yet be able to be verified as having quite reached its full value. Therefore a useful MOV is one that takes into account an acceptable lifespan of measurement but this introduces many more factors.