The Laws of Accountability

Accountability is a word that is thrown out very frequently these days and, maybe, correctly so.  However, I find that every persons version, or understanding of accountability is different.

Wikipedia compares it to responsiblity and lists several different types of accountability – talk about confusing.

Oxford Dictionary defines it as “the fact or condition of being accountable; responsibility”

A Project Manager I know defines it as “I will try my best”

Take your pick or make one up of your own, but what is clear is that when two people are talking on this topic, they are probably talking about different things and different standards.  The best colloquial definition that I have heard is “having my neck on the line…”.  Even that is open to interpretation.  Aaaarrrggghhh!!!!!

In my opinion, accountability, in professional terms, is not a deliverable.  It is an approach, an attitude, a culture; which is imbued into individuals and organizations that deliver.  It is very difficult to create a “law” around this; but, I decided to give it a shot anyways.  Without further ado, and with due apologies to the Late Sir Isaac Asimov, here goes.

1. An accountable person may not harm the objective, or through inaction, allow the objective to come to harm
2. An accountable person must drive the solution, including tracking and resolution of all dependencies that exist in achieving the objective
3. An accountable person must escalate issues out of their control before they impact the achievability of the objective

These laws can’t create culture by themselves, but they can definitely stop answers that we are all too familiar with.  Also, these laws will not make the person aware of their accountability, or bring them in alignment with the objectives – those are external actions that must happen before these laws become applicable.

But, these laws (or something along these lines), can clear the communication, set the expectation, create a benchmark, etc – something that we try to do for all important things in our professional lives.  And accountability is something I consider really important.

From the 9-to-whatevers, looking for comments on the laws – critiques, suggestions, improvements, etc.  Maybe we can all get on the same page – does anybody want to take the accountability for that?

Software Quality Improvement: Is Something Afoot?

When I started my career, the attention was still on hardware quality.  Machines with redundant hardware were the rage and VERY expensive.  However, realization soon dawned.  Analysis from the researchers pointed out that the incidents and costs from software failure were higher – turning the paradigm on it’s head.

Little has changed since then – software continues to have quality issues with resulting impacts on productivity, accuracy and even reputation.  What has changed are the issues.

Historically, issues were with stability; software would crash or freeze at the most inopportune times.  Today, thankfully, this is not the case.  Even a version 1.0 software rarely shows this kind of behaviour [barring cases where the client or end-user is being used as a beta tester!]  This is true of consumer, third party and internal software.

Issues today are different.  They tend to do with functionality, usability, resource usage [specially on mobile platforms] and, IMHO, the biggest humbug today – security. 

Functionality and usability are two issues which can be solved by getting closer to the end-client.  What do they really want, and how do they use the software?  However, this is not something that seems to be coming easy to our teams; specially for internal software though commercial software is not averse to showing this trend.  In addition, reliability in the functionality is also suspect.  These issues are, often, caused by bad coding, which is avoidable.  The vision of IV&V [Independant Validation & Verification] has not really achieved everything it set out to do – practitioners still need to work out the chinks. 

The security issue seems to be a whole different ballgame.  While this may also be caused by bad coding, work done at design time does not seem to be enough to ensure security.  Given enough time, it seems, hackers can figure out a way to identify and exploit weaknesses given the multiple tools at their disposal.  The only way to stop this from happening seems to be at run-time.

This is not a new solution.  Academia has been conducting research in the fields of self-healing and self-defending software for some time.  However, there has been no framework or usable toolset coming out of this research which seems to have been running for longer than a decade.  In trying to find data among recent articles, I was only able to find two.  A partial implementation by IBM Israel and an April fool’s joke.

To me, this is a sad state of affairs given the potentially beneficial implications.  This is not an easy problem to solve, but neither were the problems this industry has solved over the past decade.  With the resources available and the potential for this market, the lack of visible effort in this area is surprising.  The question I want to ask is “whereforth art thou open source…”

If there is work that is ongoing that I have not been able to find, please do enlighten me!

Working With Internal Clients

We all work with clients in our professional life. There is a large number of us who work with external clients – the kind we generate our revenue from; for a large number of us, however, the clients are internal to our organization. These internal clients may then work with the external client directly or the chain may be longer.

Is there a difference in dealing with the two? To begin with, let us talk about the similarities – in both cases, we need to address product quality, service quality, engagement levels, ROI for the client, and the ilk. I cannot think of many significant parameters that would not apply to the internal client.

However, there are significant parameters that need to be considered in addition when dealing with internal clients:

• Captive Relationship  With internal clients, the relationship is in captive mode.  The client is forced to accept the service from you.  This breeds complacency.  As Google also says, complacency leads to a reduction in the motivation to improve – something we need to be very careful of.
• Benchmarking  As the relationship is captive, there is no competition to benchmark onself against.  You need to develop a very clear structure of KPIs and SLAs along with your client which will allow you to measure and track you performance and it’s progress.  Without these objective measurements, ROI calculations and other benefit statements will be difficult to determine.  This will replace the pricing and product feature/range efforts that determine success in a competitive environment.
• Strategy  As part of the same organization, both you and your internal client will be part of the same strategy framework.  In your day to day offerings, you need to defend the principles of this strategy.  This means standing up and saying no when the client requests go in a different direction.  This is tougher with internal clients since you can’t just “walk away”.

In essence, working with internal clients can be more challenging in certain areas, demanding external clients notwithstanding.  Well, are we 9-to-whatevers up for it?