Archive for the ‘Corporate IT’ Category
A path-based approach to corporate IT
CIOs the world over struggle to keep up with ever changing business requirements. At the same time, many companies feel short-changed by their IT departments, which end-users often perceive as being inflexible and slow to respond to changes in business needs. This lack of flexibility can usually be traced back to TItanic-like enterprise systems which straitjacket businesses into certain ways of doing things. In an article entitled Radically Simple IT published in the March 2008 issue of the Harvard Business Review , David Upton and Bradley Staats propose a “novel approach” to the design and development of enterprise systems. They call the approach path-based because it provides a path for systems to be developed over time, incorporating changing (or missed) requirements along the way.
The path-based approach is based on the following tenets:
- Meld IT and business strategies together: The authors reckon that IT-business alignment, as it is usually presented, is hard to achieve because of a lack of mutual understanding between the two sides (this is something I’ve alluded to in an earlier post on project communication). Most discussions between IT and business tend to focus on individual projects rather than the big picture. The latter, however, is integral to a path based approach. To ensure that both sides understand each other, the authors suggest that IT staff be encouraged to understand the business and vice versa. This recommendation is far from new – see this article from 2005, for example.
- Keep things as simple as possible: The article recommends that CIOs should strive for simplicity in their IT environments, thereby ensuring that systems remain flexible (i.e. open to change). Some ways to achieve this include:
- Adhering to a minimal set of standards, so that the company has a standard operating environment at the client and server level. Additionally, standards should be recommended for specific applications.
- Evaluating whether new functionality requested by the business can be provided by existing software.
- Looking for simple solutions before buying or building complicated ones.
- Developing a modular enterprise architecture . This is essentially the notion of loose coupling – where individual systems are built in such a way as to minimise effects and dependencies on other systems.
- Empower end-users: All project and IT managers know that the biggest resistance to new systems often comes from end-users who, quite naturally, are reluctant to change their ways of working. Without end-user buy in, any new system is doomed to fail. The authors recommend reducing such organisational resistance to new applications by rolling out changes gradually. They also recommend soliciting user feedback on a continuous basis. The feedback should be acted on (and be seen to be acted on) in a timely manner so that users know their input is taken seriously.
The above principles are hardly new or radical, and few CIOs would question them. The path based approach really amounts to a consistent application of these in a (often difficult and ever changing) business environment. The authors illustrate the approach through a case study based on the experiences of Shinsei Bank. The case study is helpful because it provides concrete examples of application of the principles discussed. For more on the Shinsei story, read this transcript of an interview with Jay Dwivedi, the CIO responsible for implementing a path-based approach at that bank.
The article is well written and makes a good case for implementing such an approach in just about any corporate IT environment. However, many CIOs – particularly those stuck in organisations that don’t appreciate the strategic value of IT – will find it hard to put these principles into practice. But try they must, else their departments will continue to be viewed as cash sinks rather than strategic assets.
Great expectations and how to manage them
Many project management books contain a section or two on managing stakeholder expectations. The emphasis in most of these tomes tends to be on the bureaucratic aspects of the process – developing stakeholder management plans or getting the project scope statement signed off, for example. Although documents and signatures may be useful in proving that you’ve performed your duties with due diligence (aka CYA), they don’t guarantee stakeholder satisfaction. Despite reams of documentation, a good number of projects are deemed failures because of a mismatch between stakeholder expectations and completed deliverables. I’d go so far as to say that chronic project failure is one of the main reasons why many corporate IT departments get a bad rap.
The root of the problem, in my opinion, is that documented requirements very often do not reflect what a client really wants. It is impossible to get a comprehensive view of client requirements in a limited number of analysis sessions. This difficulty is particularly acute when one tries to document all requirements in one go, as is the case when a waterfall development methodology (also known as Big Design Up Front or BDUF) is used. It is well known that Iterative / Incremental methodologies are better because they ensure that requirements are reviewed and revised several times in the development cycle. Incidentally, this article by Joe Marasco has an excellent, visual explanation of why iterative development is superior to BDUF. Despite this being common knowledge, many corporate IT departments remain stuck under the waterfall. Why this is so is a topic for another post – I’ll just take it as a given here. However, consequent stakeholder dissatisfaction is one of the major reasons why these departments have low credibility within the organisations they serve.
So what can be done about this?
The two-word answer: better communication.
The one-sentence answer: adapt flexible stakeholder management practices from the Iterative/Incremental world and integrate them into your BDUF approach.
The longer answer:
Iterative/Incremental approaches mandate regular meetings between stakeholders and project team members. Consequently these methodologies have stakeholder management built in, as opposed to BDUF approaches which don’t require regular interactions. So when using BDUF methodologies one has to work doubly hard at communicating with stakeholders. When doing so, it is a good idea to adapt practices from Iterative/Incremental approaches and integrate them into your development methodology. In particular, the following points are worth considering:
- Frequent feedback: You don’t need to schedule formal meetings to give people status updates or feedback. Wander over to their office to have a chat and give them an update. If you make a habit of this, you may even find that formal meetings are required less often.
- Frequent delivery (or demos): Although BDUF methods appear to preclude frequent delivery (as opposed to Iterative techniques, which mandate frequent releases), it is often possible to show users work in progress. Schedule informal demos of work in progress where a developer shows end users the current state of the product. By doing so, you may get feedback early enough to do something about it. It’s no good having users complain about the user interface at the final demo.
- Flexible attitude: Yes, I know, your requirements are frozen (the users have signed off on them, after all). However, if you can accommodate changes, it is best that you do (via whatever change control process you have). A blanket, “Next phase” response to all change requests will only annoy your clients. A flexible, can-do attitude will go a long way in getting users “on your side”. Once they see that you do your best to help them, they’ll (usually) reciprocate by not asking you for the moon. Further, on the rare occasions that you turn them down, they’ll (generally) understand that you’re doing so for good reasons.
- Present alternatives when saying no: This is important. If you do have to say, “No” to a user request, try to present a viable workaround or alternative. Often, a well thought out alternative may be more than enough to satisfy the user. Besides, it also gives the user a sense that you are working with them to solve their problems, and not off on your own trip building something that is divorced from their needs.
That’s it. I know, when you look at the list the points seem pretty obvious. However, they are hard to apply in practice – not just because of recalcitrant users, but also due to the numerous constraints on project teams operating in BDUF environments. In practice you’ll also find that these techniques work better on some projects than others – mainly because of differences in user attitudes.
Everyone has great (or should I say, inflated) expectations from things to come. This invariably leads to disappointment in the end. A good part of managing users is to make their expectations more realistic rather than lowering them. The best way to do this is by involving users as much as possible in the development process. This essentially is what Incremental/Iterative and Agile techniques advocate. BDUF practitioners – which include many corporate IT development teams – should take a leaf from their book.
Solutions in search of problems
History repeats itself; first as tragedy, then as farce – Karl Marx.
Although Mr. Marx didn’t say anything about repetitions beyond the second, one can safely assume he would have considered them beyond farcical. Yet, in the world of corporate IT, we’re continually faced with the following repeat offender: the solution in search of a problem (or SSP). I should define the term before I go on – a SSP is a project that has been sanctioned without any regard to the actual value or utility of the deliverables. This post is aimed at assisting project managers in identifying a SSP, so that they can take appropriate action when confronted with one. This basically amounts to of the following: sidestep it (i.e. duck it somehow), step down (i.e. resign) or suffer (i.e. accept the responsibility of managing the project and, well, suffer).
So, here we go then, seven deadly signs of SSPs:
-
No one knows what the project is about. Everyone talks about it, but no one seems to know why it is being done.
-
It’s all about technology or standards (SOA anyone?), not the business. The justifications on offer for the project are seasoned with phrases like “best practice” or “state of the art technology”; terms that have more to do with technology than business need.
-
There’s a committee responsible for implementation (often with a global reach). You’ve got to love global committees with their 10,000 metre view of ground level realities. Most recommendations that emerge from these are either so general as to be unusable, or worse – patently incorrect.
-
Since no one knows what it’s about, the project is more about the means than the end. Put another way, project management processes or process improvement methodologies in their full bureaucratic glory will reign supreme. Be sure that you’ve filled in all the right forms and have all the right signatures, else all hell will break loose.
-
No one is aware of a successful implementation: The global committee has little to show for their three years of the project, barring the pilot they did two years and nine months ago, involving 1.5 users.
-
The project will replace a perfectly good existing solution: You have a good system in place? Don’t worry, the SSP will replace your tried and tested solution with one that will give your staff many hours of debugging fun, and the gray hairs to prove it.
-
And finally: these projects often originate in the upper reaches of the corporate hierarchy, where the connection with ground level reality is somewhat tenuous. Corporate mandated projects have a fair chance of being SSPs.
So, it isn’t hard to spot an SSP. What do you do if confronted with one? Well, that’s up to you. As mentioned earlier, you have three options: sidestep, step down or suffer. The choice is yours.
Eight to Late 