Jean-Marc's infotainment stream

« Expand/Collapse

Management Blog

May 06, 2009
17:06
The Ten Commandments of Egoless Programming
» ‎ Management Blog

While browsing Jeff Atwood's blog, I rediscovered something from my very early IT education, The Ten Commandments of Egoless Programming. There is a downloadable copy of the commandments on TechRepublic.
February 02, 2009
14:31
Multi-tasking Must Die: 5 Ways to Single Task
» ‎ Management Blog

Thank you to Mike Cottmeyer for this link to The Slacker Manager.
December 24, 2008
12:31
Cool...
» ‎ Management Blog
A while back, we delivered a presentation to a customer. Throughout, comments of "cool" were being uttered. We left quite pleased.

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
October 30, 2008
21:17
Can you see good performance?
» ‎ Management Blog

Most architects that I know pay very little attention to their reputation and visibility within their organizations. They typically consider such activities with contempt. It is playing politics, it is putting style over substance, it is dishonest.

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.
October 05, 2008
21:37
Effective communication
» ‎ Management Blog

Anglo-American business communication has evolved a terse and concise style that is accepted as conventional wisdom. However, I'm not convinced that saving the time of a few senior managers is really an effective approach to communicating organizational goals .

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.
September 07, 2008
10:16
Google Chrome - another browser that doesn't quite work?
» ‎ Management Blog

To do my work each day, I have Outlook, Word, Excel, PowerPoint, Freemind, maybe another well established Windows or Java application, plus a browser open. The browser will typically have 5 to 10 tabs opens. I am switching between these various applications continually which is why I want them all open. Given that Windows is now an ancient operating system, I don't think this is an unreasonable way of working.

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.
August 03, 2008
18:00
A classic race...
» ‎ Management Blog

It is no secret that the main Indian outsourcing companies have ambitions to move up the food chain and to be seen as mainstream players in the high end markets dominated by the "red brick" tier 1 consultancies. The Offshoring Times reports on this development in it's article Newer offshoring models in the offing.

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.
July 13, 2008
8:45
Recession = Bureaucracy
» ‎ Management Blog

In the last economic downturn, or was it the one before that, I was going into a meeting with a client when our host said, “sorry there are no biscuits today”. He explained that, every few years, sales would take a dip and the company would react by stopping the purchase of biscuits for meetings and when things got really bad, tea and coffee would also be stopped.
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.
June 29, 2008
11:16
Think More Creatively ~ Innovate More Profitably
» ‎ Management Blog

I was thinking about writing a blog on creativity, I did a little research and discovered www.jpb.com which is the site of the Jeffrey and Panida Baumgartner (JPB) group of companies. The site contains some interesting and useful articles on creativity and innovation. The site says the things that I was about to say much better than I can, it also says a lot more and is more credible. The link is in the management section of this site.
January 18, 2008
7:51
Extending the "W" Model
» ‎ Management Blog
Serge Thorn provides the following definition - “Requirements Management is the science and art of gathering and managing user, business, technical, functional requirements, and process requirements within a product development project”. This triggered the thought that most manage requirements practice that I have seen operates from a project perspective rather than a business perspective. That is, we take requirements in and ensure that we deliver them.
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.
December 24, 2007
10:10
Why do projects fail in large enterprises? - some thoughts
» ‎ Management Blog
James McGovern in his blog, “Why do projects fail in large enterprises?”, makes a number of important statements
- “how come open source projects can deliver high quality on time when folks don't even talk to each other”
- outsourcing is “about taking otherwise junior IT folks and making them usable regardless of their actual individual competencies”
- outsourcing firms “have convinced others that process can become a substitute for competence”
- “think of open source as a methodology for software development”
- “in an open source project, the architect is king and folks follow him”
- “project managers with budgets and deadlines are handcuffed to delivery of perception management at the expense of high quality software”
- “it is still fundamentally easier for me to put crap code into production at work than it is for me to do the same with almost any open source project”
The key messages here are “open source communities tend to prefer competence over process and hence can develop higher quality software” and “with experience and a desire to participate in a community comes quality”.

I agree and disagree with James!

I agree that the balance between project manager and architect is often wrong – this is a well known problem summarised by the eternal triangle of project management. The project manager is responsible for the tangible dimensions of cost and time to benefit. A motley array of solution engineers including architects, configuration manages, release managers, quality champions, requirements managers, etc are responsible for fitness for purpose. While this area operates in this way, quality will never get on the steering group agenda.

I agree that many of the techniques of open source and agile can be deployed to improve large scale solution delivery. Test first, pair programming, frequent builds and smoke tests, prototyping and a range of “non-traditional” techniques can be applied to projects of any scale and geographic distribution with positive productivity and quality effects. We need to stop dressing these up as some great agile revolution – it dilutes the message, it puts people off, it sounds like a risk. These are just good practices that have been out there for a long time – I used all them at least 20 years ago.

I disagree that with the view that only experienced teams can deliver successfully. I have taken teams of trainees and delivered high quality complex software rapidly. We need to find a way of growing people. We need to find a way of delivering the less interesting parts of a solution. We need senior people who are interested and creative in growing junior people. Delivery teams must contain inexperienced staff for solution delivery to be sustainable.

Process is never a substitute for competence. Correctly applied process teaches, supports, and grows people. Process needs to be applied in a balanced pragmatic manner with a view of the competence of people, the technology risks, and the time and cost constraints. This way it improves productivity, minimises bureaucracy and improves quality. Poorly applied process does the opposite. To apply process correctly – you need managers who have a balance of delivery and software engineering skills.

There is an implicit and sometimes explicit view that software delivery is the most important aspect of a project – this is 100% wrong. It is the deployment of a new business capability and the consequent delivery of business benefit and sometimes “crap code” in production achieves more for a business than good code later. It may deliver more business benefit to have 100 staff fixing data errors on overtime than to wait a month for the code to do it. Benefits delivery is the measure not quality.

A great thing about the open source community is the sense of purpose and commitment to delivery. High performance teams share this high level of motivation. A commitment to developing high performance teams and a commitment to developing leaders is essential to improving delivery. The leader needs to have a mix of skills – project management, enterprise architecture, software engineering, teacher, and politician.

One area I do disagree with James is that Indian outsourcing teams think process is a substitute for experience. If you use an outsourcer then challenge them to show you how CMMi benefits your business. Challenge them to increase the benefits both in terms of quality and productivity. Get them to show how they have already done this. Ask them what you need to do to allow you to maximise benefits. Work collaboratively with your outsourcer – you made them part of your business.

What do we need to do?
- Develop hybrid solution delivery leaders with a balanced mix of programme management and software engineering skills
- Leverage experience in large teams with a mix of skill levels to create high performance teams
- Create and sustain high performance teams
- Unify the solution engineering team
- Leverage delivery best practice which include techniques and process ruthlessly to drive quality and productivity
- Focus on benefit delivery and make transparent and rational compromises over quality
November 30, 2007
22:52
Enterprise Architecture: Ten Reasons why Outsourcing tends to fail... – A Repost!
» ‎ Management Blog

First, I must declare an interest – I work for a leading global IT and business process outsourcing services provider.

More importantly, I must counter or clarify the ten reasons that James Govern has cited for outsourcing failure. I am not going to say that outsourcing is always right or that it never fails – on the contrary, the reasons listed are in general correct but the industry and its customers are learning. James has written an outline for a supplier evaluation, if you choose an outsourcer then they should be able to satisfy you on all these points. There are answers…

Cost-reduction expectations
James is half right here! An outsourcing strategy should be more sophisticated than cost reduction. However, the assertion that the cost differential cannot be sustained is flawed. First, the US Dollar will stabilize against other currencies. Second, as the labour pool in India is further expanded beyond the tier 1 cities, wage inflation is likely to reduce. Third, the offshore labour force is being developed in many countries around the world which will further restrain wage inflation.

Data security/protection
Large organisations will typically have many sites that are sited in different countries. They are already communicating with their suppliers and customers electronically. Adding another business partner, the outsource supplier, poses no greater security challenge.

Equally, the same organisations have contractors and dissatisfied employees who are just as capable of injecting malicious or insecure code. A mainstream outsource supplier will have invested in security technologies and processes that most large organisations can only dream of. They have to in order to be credible.

Process discipline (CMM)
James hints at three issues here. The first is poor implementation of new processes. As with all best practice processes, they require best practice implementation. Good process implementation will, in general, speed up activities, reduce risk and costs. Initial implementation will often have some flaws. Process integration between the client and supplier organisation relies on cooperation by staff at the client organisation. Over time these flaws will be eliminated because the mainstream suppliers use self optimising processes.

The second issue relates to how the experience client staff work with the new supplier. Well designed process and organisational integration between the client and supplier will leverage the value of the experienced, heavyweight folk that work in client organisations. This takes effort on both sides, the supplier will have gone through the transition many times and will be able to advise on how to make it work.

The third issue is the assertion that experienced folk don’t need heavyweight processes. This is correct in most cases because these guys will have discipline and judgement that means that looser guidelines will suffice. However, few organisations can sustain IT departments built entirely from highly experienced staff.

Loss of business knowledge
One reason for outsourcing is to secure organisational knowledge. In many organisations, critical and IT business knowledge is trapped in the heads of a few key individuals. This poses a major threat to those businesses. Mainstream outsourcing organisations have well developed methods for knowledge capture and dissemination. They have to be good at it because their businesses depend on it.

In the short term there is the potential that some key element of knowledge will not be captured and an issue that relies on this knowledge will emerge. Over time, this potential will be reduced and the overall threat to the organisation will be reduced. Having the knowledge formally captured ensures that the threat does not re-emerge.

Vendor failure to deliver
IT as a whole does not have a great record of successful delivery. I suspect that research will show that mainstream outsourcers have a better record than end user companies. The reason is that they are specialists at it and invest far more in getting it right than a typical end user organisation. That is why they are growing.

Scope creep
I wasn’t quite sure what James was getting here. From an SDLC and commercial point of view there different approaches to handling changes. Different outsource vendors have different philosophies and approaches to managing changes – you can get a mismatch if you don’t think this through when you let the contract. You need an outsourcer that manages change in the way that you want to manage change.

Government oversight/regulation
I agree organisations need to identify and protect their business critical IP. Any outsourcer that lost critical IP would lose its credibility in the market. Again it is an area where the mainstream suppliers have to ensure that they are secure.

Culture
Culture is a big deal. The key is to take a good look at the engagement model – a strong onsite/onshore presence will reduce the risks in this area, as will a strong vertical focus.

Turnover of key personnel
The assertion that outsourcing removes the possibility of working with good people is plain wrong. Just the opposite, mainstream outsourcers have exceptional talent.

But your role may change, and the transition will involve bringing the outsource staff up to speed and this may not be what you want to be doing. So, in some cases people will leave. But some good people will thrive on the challenge of working to a new model and will embrace the opportunity to learn that bringing in an outsourcer brings with it.

Knowledge transfer
As I outlined in my discussion of “business knowledge”, knowledge transfer is a core competence of outsourcers. Staff from an outsource supplier bring different experience that may have more or less value than that of the incumbent staff.
September 09, 2007
11:11
Ventoro Outsourcing Research Report
» ‎ Management Blog
I have added a link to the Ventoro report Offshore Outsourcing 2005: Results and Conclusions by Phillip J. Hatch, President of the Ventoro Institute. Ventoro polled over 5,000 executives around the world and spoke with over 300 offshore outsourcing vendors to identify the true secrets to outsourcing success. The report covers what it takes to:
1. Develop a successful outsourcing strategy
2. Implement a global sourcing model
3. Manage a global team
April 26, 2007
21:53
Strategy & Management Bookshelves
» ‎ Management Blog

I have updated the small list of books that I have found useful for developing business and IT strategy. I have added another small list of general management books.
April 19, 2007
18:37
RACI considered harmful...
» ‎ Management Blog

As Chief Architect I had a responsibility for defining the security architecture. We had a virus attack on some remote devices due to a supplier failing to install anti-virus software and then carrying out an upgrade using contaminated discs. What was my Responsibility or Accountability for this incident?

Formally, according to the RACI chart, I was in the clear. We had delivered the policy. The supplier had the "R" for implementation, the internal infrastructure team had the "A".

My reaction was that we, the architecture team, had dropped the ball. We had let the business down and the subsequent loss of trade was in part down to us. I had failed personally to ensure that the architecture was delivered, and my team felt the same way.

There were two things that, in hindsight, we could have done better. We should have made sure the implementation plans were complete. And we should have made sure they were carried out.

What did we do to fix things? The reaction from the team was instantaneous. They got out there and made sure the situation was fixed both short term and long term. Was this "architecture"? No, it was closer to incident management, problem management, and to project management. Did we ask permission? No. Did we step on other people's toes? Yes. Did we violate the RACI? Yes. Was it the right thing to do? Absolutely!

Was the RACI chart wrong? No. If we were to get the RACI to cover every situation then we would be working on it for ever. And we would tie ourselves up in bureaucracy trying to deliver it.

There is something for more important than the formal RACI statements. It is pride in a job done well. It is the personal contract with yourself. It is the expectation that you have of yourself. A high performance team develops a shared expectation.

Why is RACI harmful? It devalues pride. It allows you to point the finger at someone else when in reality you could have done something. It allows you to abdicate your collective and corporate responsibility to do the right thing, to be helpful, to be a good citizen. It encourages the worst kind of institutional politicing.