Chief Architect

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.

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.

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

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.

1. Develop a successful outsourcing strategy
2. Implement a global sourcing model
3. Manage a global team