This is a Flickr badge showing public photos and videos from Chief Architect. Make your own badge here.

Search ...

Powered by Squarespace

Management Blog

Discussion on a variety of general IT management topics.


A classic race...

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.


Recession = Bureaucracy

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.


Think More Creatively ~ Innovate More Profitably

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.


Extending the "W" Model

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.


Why do projects fail in large enterprises? - some thoughts

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