Technology Solutions Blog

Everywhere I go, I see departments that strive to meet their functional obligations.  IT wants to ensure information is secure, HR wants to maintain legal compliance, and Accounting has to maintain financial order.  These are all necessary functions and are critical for organizational stability and risk management. 

But what happens when functional obligations run counter to an organizations strategic goals? Does a department sacrifice control and authority (temporary or permanent) of a process for the benefit of the entire organization?  Or do they minimize their risk, stay in the comfort zone of their domain, and not act “as a team player?” 

Most organizations I work with ask that all employees act in the best interest of the organization.  All too often though, those organizations maintain an environment that does not facilitate or reward that behavior.  The challenge for them to achieve this request is two-fold-

1. Risk/Reward:  Organizations tend to measure performance and productivity on functional obligations.  It is far easier to evaluate performance in a bubble than to define and quantify the value added to the organization as a whole.
   For example, many companies use a “pay for performance” compensation plan that rewards employees financially for saving the company money.  Too often though, this is measured by hard savings/benefits and does not take into account displaced costs (to other departments or deferred).
   Additionally, organizations with this model tend to focus on continuing to do the same, just at a lower cost.  This inhibits process evolution and opportunities for new services/functions to be implemented. 
2. Process Visibilty:  For employees to prioritize on strategic goals, they have to first understand those goals completely and must have visibility into the processes involved in achieving them.
   This is important so that employees understand their role in achieving those goals as well as the roles of all other process participants.  I commonly see organizations where departments fully believe that other groups try to hamper their ability to succeed by not supporting their functional obligations.  This is rarely the case, most often the other groups are just trying to meet their own obligations.  Visibility into all functional obligations as well as the organizations strategic goals goes a long way in removing conflict between departments/groups. 

Visual aids always help-

Functional Obligations Vs Strategic Goals

Technology Solutions has been officially certified as a Minority-owned Business Enterprise (MBE) by the MidAmerica Minority Business Development Council (www.mambdc.org).  Technology Solutions is owned by Eric Rowcroft, a Native Alaskan and tribal member of the Central Council of Tlingit & Haida Indian Tribes of Alaska (www.ccthita.org).

The formal certification allows businesses and orgnanizations that work with Technology Solutions to meet contract or internal supplier diversity program requirements. 

For more information, please do not hesitate to contact us!

I had to call a support line yesterday and as usual, was required to enter my phone number (I won’t go into why I enter it and the operator still asks for it..). The kicker is that after entering my 10 digit phone number (they specifically stated the number of digits), I was instructed to enter hit the pound key.
I’m always amazed when a system requires a completion notifier after a known value length.
Now, the phone system may be old and require a completion notifier, but I see this in software development on a regular basis.
Simple things like moving to the next box when filling out a form or the extremely annoying “are you sure you’re sure” dialogue boxes.
The approach I’ve taken for this is adding a section to a Software Requirements Specification document detailing the expected behavior for the UI of a system. by defining upfront the expectations of the application interface and interaction with a user (as painless as possible), developers have a (limited) creative license to apply practical flow and common sense to application development.

I’ve heard variations of this phrase and I think it applies to process as well. 

“If you’re looking for a perfect process, this isn’t it.
If you find a perfect process, don’t use it.  You’ll break it.”

I see a lot of frameworks or methodologies that look perfect on paper and are guaranteed to save an organization money, create successful projects, and make a perfect cup of coffee.  I have though, never seen a framework or methodology that was a perfect fit out of the box. 

The successes I have seen always include a practical adaptation of a framework/process to the environment it’s implemented in.  The common challenges in this seem to be communication inside an organization and an accurate and shared understanding of the purpose of the process (customer needs, regulatory compliance, etc). 

If you would like to discuss how to successfully overcome these challenges, feel free to contact us.