A friend of mine sent me some definitions of "cool".

In short, it can mean...

1. I like what you say
2. I don't know what you are talking about
3. I'm just filling the pauses until I can get out of here
4. I don't care about your opinion

Dishonest?  Yes, dishonest! Why?  Because every delivery is a team effort.  Any one person taking credit is disrespecting the other team members.

So what do you do in a culture that recognizes and rewards those who glister rather than those who just get on with their work and do an exceptional job.  Your choice is stark - play the game, move on, or accept it.

As a manager in such an environment though you have responsibilities...

A manager of mine when he understood what was happening said "perhaps I am looking in the wrong place".  You cannot rely on the grapevine to provide an accurate picture of performance.  The news spread by others is biased, it is politicized, it carries the advertisements of the carriers.  You have to get out there and continually and consistently look for yourself.  You must take a deep interest in the capabilities, aspirations, working environment and efforts of your staff.  Only then will you will you start to get an accurate picture of the performance of your staff.  And only then will you be able to help them.  Only then will you be doing your job as a manager.  Only then will you find excellence.  You will find the gold.

You have another responsibility.  Once you really understand performance rather than the reputation created by rumor, gossip and innuendo,  you must pass on good news.  Your staff deserve to have their strengths and triumphs trumpeted.  They deserve a strong positive reputation.

But what is they are not doing well.  This is also your responsibility.  Do you really understand them, if so then you would deploy them to use their strengths and they would do well.  If they are not doing well then you are failing.  Trumpet their strengths, deploy them correctly, give them the means to achieve success.

Why?

I have learned both through instruction and experience that to communicate with those of differing backgrounds and cultures that saying the same thing in multiple ways, providing additional context and painting rich word pictures are essential. If I do it and equally if those that I am communicating with do it then there is a greater prospect of mutual understanding.

Surely, business effectiveness is better served by waffling to mutual comprehension than by adopting the cultural norm of clipped, brief but turgid messages that are misunderstood.

The unpaid open source developers of Freemind are excused from the complaints that are to follow.  The product does the job I ask of it effectively every time I use it, the upgrades are useful, the beta versions are stable, performance is good even with last year's PC specification.  It is indispensable in the process of getting to grips with a new project, a new technology, in planning and managing my activities.  It demonstrates that it is possible to create and maintain over the years a stable, focused and effective product.  I only have praise for the product and its developers.

The first "office" suite of applications that I can remember using on a NorthStar Advantage micro-computer consisted of WordStar, Multiplan, dbase 2 and I don't think we had any presentation software.  This computer ran CPM, had 64k memory, 180k 5.25 single sided variable density floppy disks.  Connection to a mini computer that we had was achieved by me building a cable and then writing some code on both boxes to make them talk.  It was crude, far less capable and I absolutely don't want to go back.

The interesting thing though is that I probably pushed Wordstar to its limit then and used maybe 80% of its functionality regularly.  Today, I probably don't know what 80% of the functionality of Word is.  I guess I use 5% of it regularly to do the same job that I did with Wordstar.  Is it more effective to use? I am not convinced.

However, the comparison of Word with Wordstar is not important.  It is the contrast with Freemind that is.  They are both modern packages that do critical jobs for me.  The commercial models are different, the attitude to delivering customer satisfaction is evidently different, the development approach must be different.

What has this got to do with Google Chrome?

To work effectively, I need a fast stable multi-tab browser that correctly renders the sites that I use, correctly executes the links and buttons I click on, that doesn't cripple my PC with poor memory management, and doesn't require me to spend time researching how to configure it to get marginal performance improvements.  I think my requirement is for a basic utility that works.  Unfortunately, IE, Mozilla, Safari and Opera all fail to do this.

The reviews and forums are already full of requests that could turn Google Chrome into bloatware.  I hope that the Google Chrome developers don't lose sight of the basics in the way that I feel other browser developers seem to have.  I hope they adopt the attitudes that the developers of Freemind have and deliver what I believe that the market has been waiting for.  If they do succumb to the mountain of feature requests and compromise core browsing performance then I am afraid that Google Chrome will be just another browser that doesn't quite work.

As this survey from Business Today shows, the tier 1 consultancies are expanding rapidly in India.  This creates an interesting situation where strong local players are trying to make offshoring work.  In parallel with this, the Indian players are expanding their onshore presence and developing new engagement models to deliver high end services such as large program delivery, transformational outsourcing and strategy consulting.

Right now, the traditional local players appear to have an advantage in this race.  They have the "sales face", they have the offerings, and the onshore people.  Offshoring can be presented as making already good value propositions cheaper.

However, there are three components to successful global delivery.  The onsite engagement model, the offshore delivery model, and the on/offshore management model.  The Indian companies have an undoubted advantage in all three components for commodity IT services, it is more patchy for high end services but there are examples of success to be replicated.  The traditional consultancies are disadvantaged by using a local workforce that is largely ignorant of the dynamics of providing offshore services. 

The race is about people, capability, organization, process and culture.  These are exactly the challenges that face clients engaging in transformations and large program delivery.  The talent required both by clients and for internal change are scarce, senior and expensive people. 

Given that a side effect of the current economic downturn is an increased focus on utilization, there is a classic tension between short and long term benefit.  The long term winners will be those that put sufficient and timely investment into creating the new operating models.

Right now, across the world companies are tightening their expenses policies, new rules are being issued. Unnecessary trips are being cancelled. It all looks good, a leaner more streamlined way of working with less waste is being forged.

OK, that’s the sales pitch. What is reality?

One of the strange side effects of entering a recession is the rise of the petty bureaucrat. You need people to devise the new rules, you need people to enforce them. The way this happens is quite interesting. You don’t get more administrators – that would give the wrong signs. What happens is operational managers devote more and more of their time to administering the bureaucracy. They have to spend more time justifying petty expenditure or getting other managers to pay for it.

The effect of turning managers into administrators is that they spend less time managing. Their staff get less direction, the overwhelming message that is presented is that costs must be cut. Staff behaviours change to avoid being seen to be spending. The focus goes from doing the right thing to not being seen to be doing the wrong thing and, guess what, operational performance drops.

Barriers are put in front of people travelling, there are less meetings and those that occur have fewer attendees. This is seen as leaner decision making but it is decision making where the experts needed to advise the decision makers are absent and disenfranchised. Decision making and communication suffers and operational performance drops.

Barriers are placed in front of people working with other projects and departments on an ad hoc basis, every hour must be accounted for and every request for help must be formal and approved. Communication and collaboration suffers and operational performance drops.

How should the organization react?

Before acting, organizations need to think through the effect of the changes that they make and fully understand the impact on the organization. A failure to think of an organization as a balanced eco-system where every action has a knock on effect will result in the law of unintended consequences executing with vengeance.

The first step is to believe that the workforce want the organization to survive, they have a basic level of intelligence, they understand that waste damages the organization, they can be disciplined, and they are motivated to do what is best. This is a foundation for self governance of costs rather than imposing blunt and counter-productive rules and procedures. Giving people responsibility motivates and encourages self sacrifice, taking it away destroys motivation and encourages self interest.

There will be unnecessary victims of the current downturn. The road to organizational decline and lay-offs is paved with good intentions.

What is wrong with this? I think we generally gather requirements adequately. We sometimes don’t have a common understanding. We sometimes miss changes in requirements. But we have approaches that will pick up these issues. We have established practices to ensure that we implement the requirements. In general, I think we manage requirements into projects pretty well. Where I think we often fail is managing requirements outwards into the business.

First, let me sequence these requirements categories (and add an extra one) to this list. …

1. Business requirements – this starts with the perceived gap between where the business is headed and where the executive wants the business to be. We need to make more money – new channels, new products, new customers, new markets, sell more to existing customers, etc. Or we need to get better value – reduce costs, increase volumes, improve quality, squeeze suppliers, etc. Alternatively, there may be slightly softer objectives such as improve customer service, gain insight into customer behaviour, contribute to CSR, etc. Often there will need to be a balance between such objectives.
2. Commercial / financial requirements – constraints on costs, on timing, sourcing requirements, allocation of scope to different parties to the project, etc.
3. Process requirements – the business requirement will typically drive changes in business processes. These may be macro level transformation changes – completely new processes – or more often small adjustments to existing processes.
4. Functional requirements – this is where IT people start to get comfortable. How will data be transformed, what transaction will be implemented, what sequence of screens will be delivered, etc?
5. User requirements – users are usually interested in getting their jobs done, they want it to be easier and quicker. But don’t go too far because I may lose my job. Or sometimes, it’s the other way round.
6. Technical requirements – NFRs, performance, security, availability, backup & recovery, business continuity, etc

What’s the problem? First, we often see the business requirements as “context” rather than project objectives and frame our project objectives at a lower level. Second, we sometimes forget that implementation is a business and IT activity. Third, we don’t give the correct priority to users. Fourth, non-functional requirements are poorly collected, poorly understood, poorly planned into the project, and inevitably poorly delivered. Fifth, the commercial, financial and contractual aspects of a project are often poorly designed or poorly communicated.

I said that we usually gather requirements adequately, I’ll withdraw that because my experience is that we very often only get the functional and user requirements down well. It is generally easy for analysts to talk to middle managers and end users and they generally know what they want to do their jobs better. Getting senior executive time is difficult, getting them to walk through the business requirements in detail is near impossible – lack of time and confidentially are the excuses. Very few businesses are process aligned and very few managers are process aware. NFRs are usually vague, incomplete and wrong!

Some examples…

A project is a means to an end not end in itself. I was once the chief architect for a business transformation that was all about making a complex business model work successfully. The business had been making poor profits selling a wide range of products to multiple customer segments, the transformation was to streamline processes across the business, reducing costs and improving sales. Just as we were kicking off the programme, the board had a brainwave – simplify the business! Reduce the product range, pull out of unprofitable segments, and eliminate poorly performing channels. They cancelled the IT enabled transformation and set about a business led transformation which delivered results in 12 months instead of 3 years.

We were implementing a customer service system, we scheduled a workshop with a manager and his team to develop a caller authentication process – how would we identify them, how would we know what information they were allowed and what actions they could instruct us to take, etc. The manager turned up and proudly displayed a flowchart that he had put together. It was flawed, a caller refusing to give any information would have been given access to administrator functions!

I joined an organisation and one of the projects was to provide an information service to about 80 other companies. The project team did not understand that part of the project was to host the use of the information not just provide the information. The result of this lack of understanding of the contractual requirements was a hasty and expensive procurement and commissioning of servers at the back end of the project.

A typical approach to ensuring that requirements are met is illustrated below as a ”V-model”.

There are some problems with this approach which reflect the problems with the testing approach that it mirrors. Acceptance activities are back-loaded in the delivery plan which means that any change raised is likely to be expensive to deliver and delay implementation. The more fundamental requirements which have the biggest impact are reviewed even later. The benefits review which assesses whether the project actually has contributed requires several months of live running. In the worst case the solution could have had a negative impact. This approach also gives a project momentum which encourages “good money to be thrown after bad”.

Testing professionals developed the “W-model” to address the issues of their “V-model”. I have tried with limited success to illustrate a sort of “W-model” for requirements:

Business alignment reviews – the steering group should continually review the business objectives, the commercials and the project or programmes contribution to these. If another initiative has already delivered the benefits, the financials are off plan, the sourcing arrangements are not working, the goals or the anticipated benefits have changed then the project may need to be cancelled or its remit changed. These reviews should take place frequently for the duration of the project or programme as a steering committee agenda item.

Business readiness reviews – it is important to ensure that the business really understands what it is getting and that it has put in place the business component of the solution. This may be training, procedure manuals, publicity, staff changes, relocations, contractual agreements, etc. As change requests are raised any of these items may need to change as well. This is a continual process which will ensure alignment at a detailed level. It reduces acceptance risk by ensuring that either change requests are raised in the project early enough for them to be handled without a schedule impact or allows business changes to be made.

Commercial reviews – this is an area which can degenerate into an adversarial relationship with damaging consequences for the project. In reality, problems in this area are created by people trying to second guess the motivations of the other parties. They get it wrong but act on these wrong assumptions. When provider and customer are acting in this way you get escalating misunderstandings. Regular free and open discussions are important, understanding the commercial goals of all parties is important, stating assumptions is important.

Conference room pilots / prototypes – CRPs and prototypes of various sorts make the requirements visible in a form that is similar to the delivered system. They bring requirements to life and allow changes to be captured much earlier in the project lifecycle. They bring forward acceptance risks and can in some cases be used to support business and IT operations training.

Model office – a model office can be treated as an extension of the CRP / prototyping phase. The model office will involve more users and the solution will be at a more advanced stage. The purpose is testing rather than demonstration.

Infrastructure simulation – a typical approach to testing infrastructure is to specify - build – instrument – test – revise. While there is nothing wrong with this approach of itself. It does require environments, it does require procurement, it is time consuming and expensive. A more effective approach is to use infrastructure simulation software prior to this activity which gives a much more robust specification – it also allows multiple scenarios to be examined.

Infrastructure proof of concept – the specify – build – instrument – test – revise process can be usefully extended to give greater confidence the NFRs will be met by developing a proof of concept application that is a “mock up” of critical functionality . This can be performance tested on the proposed infrastructure much earlier than the actual application bringing performance risk forward in the schedule.

The approaches outlined are based on practices that I have applied to large programme delivery that have helped ensure we deliver the right thing.