Strategy review – are your goals still in sight?

Organizations have goals – some are questionable – but are goals nonetheless.  Once goals have been identified, a strategy (or some would say a plan)  for reaching the goals is established and put in place.  Most goals are not met accidentally.

Goals tend to have permanency associated with them.  Goals generally do not change till the goal itself is met.  When an organization changes it goals, it’s changing its purpose for existing.  This may be a good thing, but I have not seen this occur a lot.  This is not to say that goals never change, its to say that goals generally remain static.

Strategy for meeting goals is defined based on current context.  It’s highly dependent on the information available to the strategist at the time of strategy definition. While history can be taken into consideration, the future is unknown and any information based on the future is speculation at best.

A simple example for this is this: If I want to  have a goal to visit a friend that lives on the other side of town, figuring out how I will get to his place, is defining the strategy.  I can check the weather, get on Google maps and look at traffic, call him to find out if he’s at home, review the traffic incident rate on the route, see how much gas is in my car etc etc.  These pieces of discrete information are the variables that help me define a strategy for driving across the metro to see my friend.

Interestingly enough, unlike goals, even the best of strategies exhibit big time volatility. This is because the variables that influenced the strategy are volatile.  These parameters that influence strategy are subject to change due to external change agents. New information invalidates old information all the time.  Strategy does not live in a vacuum, it is influenced by changes happening all around.  But this is not new to anyone, in our daily lives, we see this all the time.  We plan for something based on information we had but as things play out, we see that the information changes.  As a friend of mine once said, no wedding goes as originally planned.

In spite of this reoccurring phenomenon, we still find organizations wedded to a particular strategy and the one-time snapshot of information that influenced such strategy.  Dare I say, that the field of “project management” as practiced by many is focused on keeping to the original plan regardless of what changes are going on around us. (Sorry my PM friends).

For some spaces, this approach may be legitimate – and I’d love to know which areas you’ve seen this make sense.  But for many organizations something more dynamic is needed.  Instead of project management (or governance as some organizations refer to it) and the insistence on conforming to a plan,  strategy management (I don’t like the word management in of itself and need to find a better word) is needed.  Strategy management focuses on reviewing the new information an organization has and determining how this new information impacts the defined strategy (plan) and ultimately the goal.

Strategy management accepts that fact that our environments are complex and hence are full of uncertainty.  Based on this, we need to focus less on long-term plans and focus more on frequent planning.  To quote President Eisenhower:

In preparing for battle, I have always found that plans are useless but planning is indispensable

This becomes quite interesting when applied to the use of technology as a business accelerator within an organization.  It’s unfortunate that many organizations have no way of quantifying how technological innovations impact organizational goals.  The technology strategy of an organization needs to be reviewed often to ensure that it is still in line to aid in meeting the outlined goals and that the best investments are being made.  A system-wide view needs to be taken to ensure that everything that needs to be considered is serving as input into determining what needs to be developed.  Kanban has a practice referred to “Operations Review” – maybe that is something your organization should consider implementing as a means of reviewing the overall strategy.

Here is the summation of the matter, define your goals and develop a strategy based on what you know.  Continually review the strategy and develop new strategies as changes occur because they will.

Advertisements

The usefulness of requirements writing

I don’t know the actual history of requirements writing and would be really glad if someone shared it with me but this I do know – many organizations with an internal technology team live and die by the presence/absence of requirements.  I know that there was a time in my career that I campaigned for them and spent long hours working on “making them better”.  In the interviews I participate in, requirements writing is always a topic that surfaces.  Currently, there is so much discussion/argument/debate around these artifacts in many environments such that the success or failure of solutions delivery is usually tied to requirements.  I beg to differ.

The unfortunate thing about this is that the individuals pushing this argument in the organization are generally technical people who should know better but we don’t.  I don’t think this is intentional but the consequences of such thinking run deep.  It impacts the working environment by creating silos and low trust.  We are stuck in the methods of the past and still feel they are required in the dynamic and ever-changing environments we inhabit today.  We forget that requirements are just a response to a need – a business gap that needs to be “filled”.  We feel that better “requirement writing” will solve the business situation.  I beg to differ.

Traditionally, these documents are some form of functional design intended to communicate to developers what needs to be developed.  We imagine that this document should simply be handed off to the developers and they’ll come back with a product.  In theory, this sounds good but in practice, it rarely is the case as we find that there is generally an impedance that needs to be worked through.  There are many questions that need to be asked and answered.  There are dependencies that exist that the requirements writer is not aware of.  In fact, review of the requirements generally turns into a whole new requirements gathering exercise.  It’s also important to realize the requirement writers are generally not the end users who are going to use the product so by the time the information actually reaches the developers, its subject to Chinese whispers.  There is so much obvious waste in this approach, I’m still surprised that it is still heavily touted.

A different approach is to have the people (business analysts) who traditionally write requirements focus on identifying gaps in the organization.  In my opinion, this is a full time job that is very often neglected because more important things (such as requirements writing) are occupying their time.  Once those gaps have been identified, business analysts facilitate a forum that allows the end users to share with the product team the gaps (requirements) that can be addressed by technology.  The team of end users, business analysts and product developers collaboratively determine the features (and estimates if need be)  that address the business gap.  The product team should have individuals capable of both capturing this information and identifying means to verify that the capabilities have been delivered.

I realize there are situations where the product team does not have access to the end users, but that should be the exception.

Doing the wrong thing righter doesn’t address anything.  We need to fundamentally change the way we work.

The Curious Case of Mikel John Obi

(This is a blogette started close to a year ago that is finally seeing the light of day).

Paraphrasing Deming, short-term decisions have long-term implications.

I wonder if Mikel’s decision to go to Chelsea has ruined what was deemed by many Nigerians and pundits alike to be the beginnings of what was going to be a stellar football career.  I remember watching Mikel play in the U21 tournament in the Netherlands and thinking he would the next big star from my homeland.

Unfortunately, after a year or so out of football due to a dispute between Manchester United and Chelsea, then finally signing with Chelsea and Jose Mourinho, Mikel was relegated to a defensive/holding midfielder position.  While it is fair to say that he has been successful in that position having won multiple trophies with Chelsea, I (and I think many Nigerians) wonder if the development of his game was stunted by this move.

His career is still young and its possible that the best of him is yet to come.  I really hope that’s the case but it’s a reminder that all decisions are not create equal and some possibly have long-last implications.

Why You Should Offshore

We are all, to some degree, slaves to our individual opinions and I’m no exception.  However, I find it a somewhat therapeutic and mind-clearing exercise to move to the other side of the table and lend my backing and support to  something that I generally wouldn’t campaign for.

Today, I’m doing this exercise with the topic of off-shoring and providing reasons for doing so.

A little bit on my experience with off-shoring.  In the early 2000’s, I had the unique responsibility of starting and growing an off-shore presence for the software development team that I was a part of.  This included interviewing countless number of applicants, hiring the the very first two folks who joined the team and mentoring them until they were fully integrated with the rest of the team.

I must say that I am very glad that I had that opportunity as it exposed me in a first-hand way to what it takes to successfully have an off-shore development team.  The long hours of telephone calls, the nights with a couple of hours of sleep, multiple (long) trips to the continent of India, are just examples of the toll that needed to be paid to get things off the ground.  I must be very careful here to note that I wasn’t the only one making that investment.  The two people who had just joined this team and were trying to succeed where also making a significant investment.  The scary thing about it quite honestly, is that I had nowhere the insight into successful collaborations as I do now.  Reaffirming once again, in my mind, that most organizations survive not necessarily because they are good, but because no one knows any better (but I digress).  This initial investment was made (somewhere between 1 to 2 years) and after that they were able to bring on others to the group by themselves and continued to grow the group somewhat on their own.  At the time I left the organization, the off-shore folks outnumbered the on-shore folks on the team and the off-shore team and were generally very productive.

So if I had a good experience (which doesn’t seem to be the case for most people), why is it then that I seem particularly anti-offshoring?  Well, because of four major reasons that I can think of right now:

  1. Most organizations offshore to reduce cost without giving consideration to the fact that there are other variables (such as quality or delivery times) that they are impacting
  2. Most organizations will not make the investment required to successfully have offshore teams
  3. Most organizations fail to understand that product development is hugely dependent on human collaboration/interactions and have the misconception that its just about smart people writing code around the clock. (Oh that’s why we’re called resources isn’t it?)
  4. Those who decide that an organization should offshore are generally least informed about what is really required for it to succeed

So dear technology executive, this brings me to the point where I give you reasons and encourage you to offshore.  As a technology executive, if the following things apply to you, then you have every reason to leverage an offshore team in your product development space.

  • The end users and the off-shore team are geographically located in the same place
  • Lowering personnel cost is more important than costs incurred by from lower throughput (at least in the short-term)
  • The products (or enhancements) being developed are not strategic and are more utilitarian or support-oriented.
  • You will make a significant technological investment in communication tools to ensure that collaboration is at its best
  • The offshore team understands the domain (and technology) fully or an investment will be made to have domain experts present to support the team locally
  • You intend to staff all the key roles required for successful software delivery in the offshore team
  • You will pay for good offshore talent
  • You will make every effort to develop the members your offshore team and provide them with new opportunities so as to reduce turnover (and having to start again)
  • You have committed onshore folks who will work to make the offshore initiative successful

This is by no means an exhaustive list, if however, you don’t intend to do these things or the circumstances don’t apply to you, venture in at your own risk.  But before you do decide, seek the advice of those who really know what product development is about (and no, just because someone has a computer-related degree, it doesn’t make them knowledgeable).

A word is enough for the wise.