Keep Your Consultants on their Toes

Hat tip to Kailash Awati’s Eight to Late Blog for summarizing the basic inconsistencies of consulting arguments from a paper on the topic.  Read this to see how to keep folks like me from getting lazy and falling back on consultant-speak.

..the original paper by Johan Berglund and Andreas Werr may be downloaded here:

Keep Your Consultants on their Toes

UMT 360: It’s Here and It’s Awesome

We’re thrilled to announce the Release to Manufacturing and General Availability of UMT 360, the latest iteration of our flagship product offering.

For more information, please check out our official blog:

Watch this and other UMT spaces for more information over the coming months.  If you’re in the Houston neighborhood, come on by our shindig on August 22 to personally kick the tires.

UMT 360: It’s Here and It’s Awesome

Everything is Discretionary

On my last(ish) post, The Road to Portfolio Analytics, fellow Buckeye and overall great guy Prasanna, asked the following question:

“Are you saying that by arriving at the costs of assets, and corresponding benefits, and a ratio of both, one could somehow arrive at common ground for prioritization?…..if yes, I would like to disagree.  For example, if I am trying to decide whether to spend money buying apples or oranges, cost (my expense), benefit (hunger taken care of), form only part of the equation. I think the real driver there is ‘Value’ (which is Satisfaction/Joy in this case). However, if it can be done, then that’s what the driver should be for project selection. And the prioritization should be based on the ‘Speed of value attainment’.”

I started responding, and it turned into this blog post.

Let Me Explain; No, There Is Too Much; Let Me Sum Up….

To rehash a bit of last week’s post, there were a couple of points I made there:

  1. Work is associated with a specific asset or program. The priority of the work is then inherited (to an extent) from the asset… are potential risks.
  2. The next question is how to rank specific assets or programs against each other. The easiest way is to quantify the value somehow, and then to map the value against the TCO for the asset.
  3. The real question is how to quantify a mandatory program such as Hunger, which in this case would be considered equivalent to a regulatory mandated program, i.e. things we do to keep our executives out of jail.

Classifying the Asset And/Or Program

Thinking through this, I think the real question is how to quantify the priority within the pool of mandatory work versus within the pool of discretionary work. For example, I have work that supports an asset that is not mandatory. The asset drives financial benefits or value. I also can calculate the cost of the asset. This allows me to identify which assets merit further investment versus those that do not.

Mandatory work is different. In the example, we used “Hunger,” which I would say is equivalent to a regulatory driven program. Sure, at this point the program may be considered mandatory, and the prioritization occurs a bit further down the work chain, i.e. if we can define our minimum requirements well enough (per identified business drivers), we can then assess new work as it comes through the pipeline to see if it gets us to the minimum acceptable standards, or if it exceeds those standards. If it exceeds the basic standards, great…..but we don’t want to pay for that if it takes investment away from other assets.

Assessing Mandatory Work

If we step back a level though, everything is discretionary. If the costs of the regulatory mandated program exceed our ability to make a profit or get capital (say in the case of a non-profit), then that would drive a decision to get out of the industry entirely and focus on more viable areas of business.  Mandatory programs need to be assessed against a higher level of benefits aggregation, i.e. the line of business which they specifically support.

Hence, while mandatory programs may not require the same level of rigor in prioritizing against discretionary programs, they still sum up to the unavoidable costs of doing business, which must then be assessed against our overall strategic goals of whether or not we want to be in that business. In a sense, it’s the same benefit-cost strategy, but as part of a more holistic approach.  Arguably, we would still need to track the TCO of these mandatory programs in order to drive any continual improvement initiatives such as reducing the overall cost of meeting regulatory requirements.


I would also contend that there’s no definite ruling as to what constitutes mandatory vs. discretionary. In the Texas oil patch, there are plenty of examples of companies flirting regulations and accepting fines instead of investing in being compliant in the first place. Arguably, that’s driven by the same cost benefit calculations discussed above.

In fact, I would further posit that simply labeling work as “mandatory” immediately prompts many organizations to simply cease doing due diligence and good governance on the work in question.  A mandatory designation is not a free pass to avoid governance….it’s merely a label that implies a higher level of benefit aggregation in the benefit-cost ratio.

…And Now For Some Navel Gazing

Of course, we could extend this metaphor to the breaking point.  If discretionary work can be measured against other discretionary work, and mandatory work can be assessed against the overall benefits of being in the business we are in, then if we truly reviewed “Hunger” as an example, that would imply there’s a third category of work with its own unique prioritization mechanism, existential.  Needless to say, I’d prefer not to got down that philosophical rabbit hole.

Everything is Discretionary

Repost: Project Server 2013 Remote Event Handlers

Check out some of the stuff our development team has been working on over on their blog:

For those of you not familiar with event handlers, my layman’s explanation is that they’re basically recordable events that you can use to trigger custom code, i.e. do x when projects publish, where the Publish event is the trigger for the code.

Project Server 2013 introduces the concept of remote event handlers, wherein code running somewhere in the cloud can pick up events in a hosted Project Online instance and then run code as required….i.e. no requirement to install custom code on your Project Server instance to extend functionality to support specific business requirements – which is often a major hurdle for many of our clients.  (The custom code deployment part, not the support bit.)

Repost: Project Server 2013 Remote Event Handlers