Articulating the Value Proposition

Finding a new job this time has been more difficult than ever before. I am quite certain that my problem has been that I have not been focused enough on what it is that I do and defining the value I can provide to an organization. With this understanding I have taken a break from the daily scan of job listings, and worked on tryiiStock_000002883983Small_Be the first_gearsng to understand and articulate the real value I can bring to the table. I think I have finally identified my focus, technology deployment and user adoption. Pretty much every job I have had for the past 20+ years has been a variation of helping people learn new skills and change behaviors related to using new technology. There it is, that is what I do.

User Adoption Problems

Ultimately the success of any IT system boils down to, “Is it being used?”. No matter how good the ROI projections are, or how advanced the technology is, or how little it costs, if users are resistant to making necessary behavioral changes, the final result will be seen as a failure.iStock_000003953906Small

I found this post by Nuvem Consulting that details the potential issues with implementing Salesforce. For the most part these issues have nothing to do with the technology per se, but instead with human nature. Their key points for failure are:

  1. Poor communication
  2. Lack of support from executive stakeholders
  3. Resistance to change
  4. Failure to recognize that Salesforce is constantly evolving
  5. No champion
  6. Inadequate or no training
  7. Processes not clearly defined or that no longer work
  8. Poor data quality

Success of most IT projects will hinge, in part, on the people and process aspects of the deployment. Dealing with these issues requires a very different set of competencies than traditional IT project management. Including resources within any deployment initiative that are specifically focused on user adoption should be standard practice for any project.

Slack Product Review: Almost Perfect

I ran across Slack a few months back, but with so many new products and vendors of Social Business Systems, I only gave it a brief glance. Last week I saw that they just raised $120M with a $1.12B valuation, that caught my attention and deserved further research. So far I have only looked through their on-site educational material, but I really like what I see. They are focused on creating a single stream of content, regardless of source, something I have been looking for for a long time. I like this! They are also (relatedly) working through integrations with other systems, and not trying to be all things in a monolithic package. Meaning you can store your documents in Dropbox or Google Docs while using Slack to handle messages related to changes in the documents. Basically there is a lot to like here, and I will let others go into more detail about all the features.Screenshot 2014-11-04 10.42.05

I want to address the one thing that I see as an “architectural issue”, Team-centricity, meaning that the “team” is the fundamental element of the system. As I understand it, if you want to use Slack for more than one team, then you need to operate in more than one instance of Slack. I would like to see the architecture operate around the individual instead, and team be a level of filtering and segmentation available to the individual. In today’s world, teams are fluid and individuals are mobile. I want to see a single dashboard that holds all of my teams so I can get a universal view of everything that impacts me, without having to jump from instance to instance. Their current architecture seems to undo everything they gained with the “single stream”.

There is so much to like here that if I can find a way around this issue, Slack may become the solution I have been looking for.

The problem with Enterprise Collaboration: Or Why I lost my Job

In 2007 I saw the light. A better way to work was about to happen, Enterprise Collaboration. A change in organizational behavior, assisted by technology, that would allow people to work together more effectively. I took that turn as my career path, first as an independent consultant, then with Cisco, and finally with Moxie Software. Unfortunately, things did not go as planned. In January of 2014, Moxie dropped Collaboration as a stand-alone product, and let me go as part of that transition. I think that all of us that were (are) working in that area have learned over time that collaboration software as a stand-alone product is a solution looking for a problem.

iStock_000006428830SmallI still believe that organizations need to do a better job of collaborating, but the path to getting there is much different that we thought seven years ago. I just ran across this article in PCWorld
that provides a little more detail. The fact that jumped out for me was:

Gartner predicts that through 2015, 80 percent of social business efforts will not achieve their intended benefits due to inadequate leadership and an overemphasis on technology…

I can attest that this was my experience as well.

The proper model for collaboration technology is to look at it as a feature within other business processes. We can collaborate better around the budget process; we can collaborate better around the hiring process; we can collaborate better around the procurement process; etc. The point is to understand the problem you are trying to solve first THEN look for the best solution, which may happen to include better collaboration…

Problems, Problems

This morning I was thinking about the nature of problems, so, of course, I googled: “nature of problems”. What I found was this great blog post by Frank Chimero. It resonated with my own thoughts. (I am always amazed by what you can find just by looking.)

The post highlights four common mistakes we often make when considering problems:

  1. We forget that there are two kinds of problems.
  2. Aspects of problems are a little bit concrete and a little bit squishy, and we mistake one for the other.
  3. We think there are solutions when there are none.
  4. We forget that our responses to problems create more problems.

Essentially all of what he says rings true with my own experience. I might add another mistake that I see:

  • We tend to confuse symptoms with problems, and thus waste time addressing symptoms instead of underlying problems.

My take away from this is that we tend to not spend enough time understanding and articulating problems in our rush to reach solutions. Finding a better way to talk about problems, is a problem worth solving.

Project Design for an Agile Workplace

Approaching the Agile Workplace

They were saying it 20 years ago, and it is more true today than it was then, “The only thing that is constant is change, and the rate of change is accelerating.” Some of the changes we have seen since the 1990’s include:


  • Software-as-a-Service
  • Agile Development
  • Remote/Distributed Workforce
  • Reorganizations too numerous to count

All of these changes are leading to the Agile Workplace, a working environment that can quickly transition in response to the needs of the market. We are not there yet, as there are still too many vestiges of hierarchical infrastructure, top-down command and control, and ego driven agendas within most organizations.

One element that is embedded in most organizations today that does support the shift to an agile workplace is the project centric approach to work. Essentially every organization in existence operates with a project mentality in one aspect or another. Projects done well can enable rapid change, but projects done poorly are merely extensions of the burdensome bureaucracies that sidetrack innovation and deflate effective operations. So the question becomes, how do we design projects that support the agile workplace?

Project Design is about Process

Project management is first and foremost about communication, making sure that the right person has the right information at the right time. The difficult part is being able to identify:

  • Who is the right person?
  • What is the right information?
  • When is the right time?

And to compound the situation, no single person ever knows the answer to all of these questions. The most common approach to alleviating this problem is to gather all the information into a project charter and project plan, and make it available to the project team. But then other questions arise, where did that information come from, did all stakeholders have input, is it current? Too often assumptions are made that lead to problems downstream. For example: a project manager may assume that the project sponsor queried all the stakeholders prior to generating the project mandate. Or the project team may assume that the root problem identified has been tied to a prioritized business need.

Explicit and open statements should drive the project forward, not assumptions. Similarly the process for generating project information needs to be open, and subject to feedback from all stakeholders.

In order for project information to be effective, not only must the content be readily accessible, but also the process and context behind the content must be transparent. When all the information about a project is available and everyone can see the roadmap for how that information was generated, only then do you have the basis for an agile project and thereby an agile workplace.

The bottom line is that the success of a project is dependent on the way you design the systems and processes that support the project. 

Mind The Gap

Most organizations I encounter possess a huge gap. That is the gap between concept and execution. Everyone loves to create the big idea, the grand plan and they want to get moving on it ASAP. Failure to “mind the gap” inevitably leads to failure of the initiative.Screen Shot 2014-01-30 at 10.27.13 AM

So what is in this Gap? We all know what needs to be done:

  • Document the current environment
  • Identify root problems
  • State your objectives
  • Create your plan for execution

The problem is that we rush through this part and/or don’t involve enough stakeholders. Frequently a preconceived solution is already in mind, which precludes any opportunity to be sure you are solving the correct problem. Filling this gap effectively is essential to the success of any initiative.

After years of working in the area of major organizational initiatives, I can say that the place I provide the most value is in Minding the Gap.

There are two parts to doing this well. First is creating a solid charter. The second is creating a thorough stakeholder map. Each task is seemingly simple on the surface. In fact each activity requires unique skills to do them well. The underlying theme in both activities is creating a transparent and dynamic conversation. Only through this process of proposal and feedback can all the issues be surfaced and dealt with before the tactical work begins.

This is what I do, and it just so happens this is the position I am currently looking for. As of today ( January 30, 2014) I am available for full-time or contract work to help organizations “Mind the Gap”.