Archive for the ‘Operational Efficiency’ Category

If found that using Wordpress, which is what is built on, was just too heavy weight for they way I’d like to capture and express my thoughts & ideas.  As a result, I’m moving my blog to a new back-end system,  Going forward I will be using the following url, not only because I’m changing back-end systems, but the purpose of my blog as evolved.

since my last post.  I’m back on the horse now and hopefully I can stay on.  I have a few posts that I have been in draft format for a while now, if all goes as expected, they will be published in the next couple of weeks.  

I’m also planning on starting a series of posts focused around a trend I’ve been seeing lately, in which companies want to be more “Agile”.  In many cases, the leadership team doesn’t really understand what this means.  They have been told that being Agile, will solve all of their problems.  As a result, too many organizations focus on being “Agile” as opposed to allowing their teams to be more efficient and productive.  After all that is the primary goal of being agile.  Just as s side note, I really don’t like using the term Agile, because it has been so abused and in many cases has a bad connotation.  I am using it because I haven’t come up with anything better.  In the posts to come in this series, I’m going to keep the posts focused on the principals/procedures that are important as opposed to the terminology.

More to come.

I recently came across a term called Commander’s Intent (CI). I briefly mentioned it in a previous post.

The core idea behind CI is:

  1. The commander’s stated vision which defines the purpose of an operation
  2. The end state with respect to the relationship among the force, the enemy and the terrain
  3. The enabling of subordinates to quickly grasp the successful end state and their part in achieving it

To put it more plainly, it’s the military’s version of the KISS principal.  There are too many variables that will dictate the actions taken by the forces on the ground.  There is no way every action can be planned out.  This is where the CI comes into play.  Each person has a clear understanding of the overall objective. Each person will do what needs to be done in order to achieve that objective.

I think that the business world can learn from the concept of Commander’s Intent. The CI defines the where and the why; a finite objective, a way of behaving, or a desired result.  This is significantly different than a  vision statement that is difficult to pin-point.  It’s a leader’s job to provide clear directions/goals for the business and to ensure that his/her team understands those goals and why they are important.  It’s then up to the team to execute and achieve those goals.

Using the concept of CI instead of a vision statement also aligns the goals of the different teams, departments, and organizations involved.  Because the objectives are more concrete.  Any time you align the goals and motivation of a group of people, you achieve significantly better results.

When a business leader tells you what the desired goals are and then lets you go and do it, they are letting you know that they have trust in your abilities to get the job done.  Trust between people is the foundation on which effective organizations are created.

The continual communication about the CI is critical to every business.  You can/should modify the means of the message, but not the message itself.  Aligning everyone’s goals sets the stage for success.

I believe that one of the most difficult tasks we face as software development professionals is scope management.  We have all been there, features are added to a system because someone from a particular business unit says the features are a must have.  When any system has multiple business stakeholders the problem just worsens.  Here is an example: a CRM application is customized because the order of the data entry fields are not the way the customer service manager would like.  In the majority of cases the cost incurred for making this type of change will never be recouped.  This is because there isn’t any additional business value in reordering the fields.  I’m sure that you have your own stories.  If so please share.

What if I told you that I could show you how to mitigate these types of decisions from happening with a simple diagram that contains four boxes and nine labels which can be explained and executed within sixty minutes?  You would probably think I was crazy, right?  I sat in on a presentation given by Niel Nickolaisen, in which he did exactly that.  Below is a modification of the diagram that Niel used in his presentation.

The key principals are to get the business owners to focus their decision making around the business value.  I’m sure I don’t stand alone when I say it is extremely difficult to get multiple business stakeholders to agree on every feature set of a system.  The diagram is a tool that can be used to accomplish this.  As features/initiatives are being advocated, two simple questions can be asked.

  1. Does this feature/initiative have significant business impact?
  2. Will this feature/initiative differentiate us in the market place?

Doesn’t Matter

If something does not have a significant business impact and is not a market differentiator, then it doesn’t matter and you should not put any effort/dollars towards those features/incentives.


If something does not have significant business impact, but does allow you to differentiate yourself in the market place, then you should look to partner with another organization.  Typically if this is the case, that is not a core part of your business.  An example here might be if your organization is a book publisher, but and would like to offer products in an electronic form over the internet.  You should not spend the dollars to build your own technology to manage the digital right and the distribution.  A better use of your resources would be to find a technology company that can take that on for you.


This box focuses on areas which have significant business impact, but are not market differentiators.  For these areas, you should try to find out how the rest of the market is doing it and copy that.  You should not be trying to out do your competition here.  In this area UNIQUENESS = BAD.  Now with that said, you do need to be proficient in these areas because it does impact your business.  An example would be invoicing & bill collection.  This is vital to most businesses, but unless this is your core business, you do not need to create a new way to do invoicing or bill collection.  Find industry best practices and follow those, use out of the box applications.


These are areas in which have significant business impact and allow you to differentiate yourself in the market.  This is where you should be spending most of your effort/dollars.  Innovation is what makes a good company become a great company.  As the axis states, this is how you will differentiate your organization from your competition.  An organization should only have two to three areas here.  Any more than that, will be a distraction.

Now when a decision needs to be made about a specific feature set, have the advocate identify which box it should belong to.  Also have the other business stakeholder vet that decision, if you don’t get consensus, push a bit more.  Once your organizations adopts this culture, you project/initiatives will shrink in size significantly.  As we all know, the smaller the scope, the more manageable it will be, and the more reliable the costs estimates will be.

See how simple it can be.  If you do try this approach, please post a comment to this post.  I’d love to hear your story.

Laying the foundation

Improve the efficiency of your team simply by changing the way you organize and think about your work. Organizations are typically composed of separate functional groups/departments that perform specific functions. Most organizations are setup this way regardless of their size or industry. Within these departments, there are the people that make the decisions (managers) and then there are the people that do the work (team). The managers are held accountable for the output of their team. Smaller departments roll up into a larger department. Those larger department then rolls up into another department and so on. Until you get to the very top, which is headed up by the elite executive team. The executive team is then responsible for the output of the entire organization. In this typical corporate structure, each department has it’s own management structure and team with their own goals & priorities. I’m sure that this isn’t ground breaking news for anyone, we’ve all seen this before.

So, what’s the problem?

The work within an organization is divided based on the function of the department and more specifically the role individuals play within that department. Managers define the work, the team executes on it. This is not to say that the managers don’t execute themselves, it just highlights that the team usually isn’t involved in the decision making process. Looking in from the outside, this all looks fairly normal and a good way to operate. You have people with specialized skills functioning within those parameters. This works really well in an ideal situation when there is enough work within each department to keep everyone 100% utilized.

Experience shows however that that there isn’t an ideal environment, there is always flux, especially in the services industry. All organizations experience this flux, which creates availability in one department while leaving a deficit in another. In most cases the groups that have an abundance of work will try to increase their team size, while the groups that don’t have enough work will either try to reduce theirs or will have availability which doesn’t add value to the organization. Availability should be viewed as inventory, you want just enough to service the current needs. Too much or too little inventory costs an organization money. There is enormous waste in individual departments continually trying to manage their own resourcing needs/constraints.

Well what else can be done, this is just the way it works. Every company faces this problem. The problem might exist for every company, but that doesn’t mean that you should try to solve it the same way as everyone else.

A different approach

The problem here isn’t how the teams/departments are structured, but how the work is divided and assigned. It turns out that this problem has already been solved, just in a slightly different context. Principals within lean manufacturing can be applied at the corporate/department levels. Instead of creating work based on functional groups/departments an alternative is to create and organize the work based task & priority. Many in the software development community have already embraced this new approach and have been applying it successfully towards their projects. Focusing the team on the tasks and priorities for the organization, puts the responsibility on the entire team not just the department heads. Teams will then organize around the task as opposed to their function, promoting cross functional collaboration. This approach allows the organization to leverage all of the skill sets of the team vs the specific function of their department. Not only can the organization take advantage of the untapped potential in their teams, but can prioritize the work based on what is going to add the most value to the company now. This now optimized the teams ability to add value and improved the overall organization efficiency.

The goal of this post is to create awareness of the problem. Subsequent posts will discuss specific things organizations can do to solve this problem.