Archive for the ‘IT Management’ Category
On the intrinsic complexity of IT projects
Several years ago Fredrick Brooks wrote his well known article, No Silver Bullet , in which he explained why software development is intrinsically hard. I believe many of the issues that make software development inherently difficult have close parallels in IT project management – parallels which apply even in projects that don’t involve much writing of code. In this post I look at Brooks’ article from the perspective of an IT project manager, with a view to gaining some insight into why managing IT projects is hard.
Brooks defines the essence of a software entity as, “…a construct of interlocking concepts: data sets, relationships among data items, algorithms and invocations of functions…” This construct is abstract; that is, it has many different representations or implementations. A line later he states, “…I believe the hard part of building software to be specification, design and testing of the construct, not the labor of representing it and testing the fidelity of the representation…” The connection with project management (especially, IT project management) is immediately apparent: the hard part in many projects is figuring out what needs to be done, not actually doing it. Put another way, requirements, rather than implementation, are the key to successful projects. Project management methodologies deal with implementation reasonably well, but have little to say on how requirements should be elicited. Why is this so? To answer this it is helpful to take a closer look at the parallels between inherent properties of software entities (as elucidated by Brooks) and IT projects.
According to Brooks, the essence of software systems (as defined above) is irreducible – i.e. it cannot be simplified further. This irreducible essence, he claims, has the following inherent properties: complexity, conformity, changeability and invisibility. These characteristics are present in any non-trivial software entity. Furthermore – and this is the crux of the matter- any advances in software engineering or development methodologies cannot, in principle, solve difficulties that arise from these inherent properties. I discuss these properties and some of their consequences below, pointing out the very close connections with IT project management.
- Complexity: Brooks describes software entities as complex in that no two parts are alike. This complexity increases exponentially with entity size. Deriving from this complexity, he says, are issues of difficulty of communication among team members leading to product flaws, cost overruns and schedule delays. This should sound extremely familiar to IT project managers.In an earlier post I looked into definitions of project complexity. In a nutshell, there are two dimensions of project complexity: technical and management (or business) complexity. Brooks defines complexity in technical terms, as he is concerned with building software. However, in large part the complexity he talks about arises from business complexity (or complex user requirements). The latter is often what makes IT projects difficult, even when there’s not much actual code cutting involved. Furthermore, this characteristic is intrinsic to all but the most trivial IT projects.
- Conformity: software entities must conform to constraints of the environment into which they are introduced. To paraphrase Brooks, “…These constraints are often arbitrary, forced without rhyme or reason by the many human institutions and systems to which interfaces must conform…” This too has obvious parallels with IT project management – the deliverables of any IT project have to fit into the environment they are intended for. This fit has to be at the technical level (eg: interfaces) but also at the business level (eg: processes). I’m sure many IT project managers would agree that the technical and business constraints imposed on them are often arbitrary (but compliance is always mandatory!). So we see that this characteristic, too, is intrinsic to most business and technical environments in which projects are conceived and implemented.
- Changeability: Brooks describes the software entity as being “…constantly subject to pressures for change…” This, he reckons, is partly because software embodies function (i.e. it does something useful) and partly because it is perceived as being easy to change (italics mine). One would think twice (or many more times!) before asking for large-scale changes to a building that has already been erected, but there’s considerably less restraint shown when asking for major changes to software. This, again, has parallels with IT project management – shifting requirements are the norm, despite the high cost in terms of time, if not money. Change control processes are put in place to dampen this tendency, but it is ubiquitous nonetheless.
- Invisibility: According to Brooks, software entities are, “… invisible and unvisualizable…,” in all but the simplest cases. Unlike the floor plan of a building, which helps project personnel visualise the finished product, no pictorial model is available to software builders. Sure, modelling techniques do exist, but they do not (and cannot!) depict the complexity of a non-trivial software system in any meaningful way. This, says Brooks, “…not only impedes the process of design within one’s mind, it severely hinders communication among minds…” Here too, the parallels with IT project management are clear – communicating the requirements of the project would be so much simpler if there were a visual representation of what’s required. If Brooks is right, though, a search for such a representation is akin to the search for the philosopher’s stone.
Yet Brooks is not a pessimist. Towards the end of his article, he mentions some techniques that can alleviate some of the essential difficulties of building software. These include: rapid prototyping and iterative / incremental approaches. Grow software, he says, instead of building it. Such an approach, which incorporates frequent interactions between users and developers, reduces risk associated with missed or misunderstood requirements and clarifies design in small, digestible steps. This is also good advice for IT project managers, as I’ve pointed out in a previous post.
In the last section of his article, Brooks states, “The central question of how to improve the software centers, as it always has, on people” and then goes on to discuss how talented designers (or architects) can greatly reduce the essential difficulties in building software. I believe the parallel here is between designers and project managers. A talented project manager can make all the difference between the success and failure of an IT project. What are the attributes of a talented project manager? Well, that’s a topic for another post, but I think most of us who’ve worked in the field can recognise a good project manager when we see one.
Brooks believes the essential difficulties associated with building software make silver bullet solutions impossible, in principle. The parallels outlined above lead me to believe that the same applies to project management. Methodologies may help us along the road to project success (and some do so more than others! ), but there are no silver bullets : managing IT projects is intrinsically hard.
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.
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 