What can’t you change right now? The installed base of legacy systems. The backlog of change requests and bugs. Senior management’s’ conflicting priorities for IT. This pent-up demand is a lake of potential behind a dam.
What can you change (or at least start to change)? You don’t have the power to just blow a hole in the dam, and the results might be chaos if you did. So, start with changing the structuring and management of the IT projects — overall management of staff by skills/specialties, and allocation of staff to the projects.
Start to lower the level and pressure of the lake by releasing “cascades” of change. What follows is a prescription for this change.
1. There is always more work to be done than people to do it. We must accept that there will be a backlog; fully eliminating it would mean that the delivery group (like IT) becomes redundant, or that the overall organization has stagnated. What must be done is to embrace the back-log; it is IT’s input material and should be managed as such.
2. Projects change the business, so know the overall business first. Some industry knowledge is required. I suggest from experience, however, that several week’s research on an industry is equivalent to several year’s work experience, as much of a person’s experience is rendered out-of-date by industry changes, or is too specific to the company they worked at. This is truer today than ever, as the ubiquitous Web makes information about almost anything available with a text string and few mouse clicks. As a result, IT needs to know something about the business going into a project, and the willingness to learn more as a project progresses. If IT people know too much about the current business, they may be unconsciously constrained when devising new IT solutions by “the way things have always been done here.”
In extreme cases, this can lead to an IT staffer having the delusional belief that they know more about the business than the systems users and their management.
3. Use Architecture to describe the business, before and after projects. Architecture is layered to capture and present information about the product to different audiences, from initial/high concept to detailed specification.
Applied to IT, a component assembly approach is dominating the industry, from the OO approach of software development, to real-time use of defined services, as popularized by SOA. Specialized agent software is starting to assist in finding services and brokering between different services to perform transactions collaboratively.
For the average company using IT, architecture is needed because it needs focused IT functionality to deliver the highest current value, while trying hard to ensure that the function will work (“integrate”) with the next function that is needed.
4. Pick the right project(s) for the business. I sat in on a senior management committee meeting where the progress to date of a grand project was presented and a request for a budget increase was made to complete the project. The CEO took all this in, and commented that this was very interesting, but given the sizable amounts of money and time expended so far, why the heck had he never heard of this project before? The next week my manager sent me to see the CIO, who charged me with coming up with a new process for defining, approving, and controlling IT projects, better known these days as “Project Governance.”
So, how do you pick the “right” IT projects? First you have to make the choice explicit, avoiding the random start-ups described above; do encourage any and everyone to suggest possible projects. An active strategic and operational planning process will also tend to drive out new projects as senior and middle management look for IT assistance to reach their assigned goals. All these proposed project ideas then become input to a “gating” process, supported by means of valuing the worth of a project like, but not limited to, cost-benefit analyses.
5. Once a project is started, finish it. Even with a good process to pick the right projects to execute, there will be a strong if unrecognized tendency to initiate too many projects at once, or initiate more projects before any already underway have been completed. This goes back to the average senior manager’s split view that most IT spending is a waste, except for their own projects. Given several senior managers in an organization expressing these views, a natural reaction is to have at least one project underway for each manager; if most of the IT efforts are applied to projects for only a few managers, the rest will complain or start looking for other options.
So, projects have to be run such that at least one is completing within each reporting period; this would be quarterly in most companies. In large IT shops with dozens of projects, it may be a percentage you aim for, 10 per cent to 20 per cent of projects completed per period. Given the common situation of limited IT resources, allocating resources to a set of projects has to be guided by a focus on completion, not competing priorities.
6. Specialize. Each member of a team assigned to a project should do what they do best for the length of that project. With limited resources, there is another strong tendency to have IT staff wear multiple hats on a project, especially the Business Analyst who is asked to also be the Project Manager and/or Lead Tester. Rather than getting more than you are paying for, you get less as an IT Staffer skilled in one role spends more time performing the other roles than an appropriate specialist would, and is distracted from being productive in their primary role.
At any time, and perhaps more so currently, there will be debates about which is better, a generalist or a specialist. I will agree that a strong, experienced generalist who can cover a wide number of tasks is the best resource you can have. However, these people are rare, and the odds of having even one such person in your average IT department are low. So, make sure that your staff is doing what they do best as much as possible as often as possible.
7. One Architect/Analyst can generate enough work for two Developers and one Tester. Structure your project teams in this ratio. This is actually one of those rules-of-thumb that have been borne out over time. (The ratio may vary a bit from case to case, like when the experience levels are different across the roles.)
8. It’s the Deliverable that matters not the Task. Once assigned a task, it is the goal of a specialist to produce a deliverable/result/artifact that can be used by the next specialist to further the progress of the overall project. Unfortunately, this simple idea has been the starting point for literally hundreds of IS delivery methodologies, many which spend an inordinate amount of content explaining how to do a task, how to amass all the tasks in Phases, and often insisting that its way is mandatory for success.
What this can lead to is an over-emphasis on the “how” of IT project tasks, to the detriment of actually completing them with all due speed. Here we see the task that is 90 per cent done for weeks, or the infamous “analysis paralysis” where a project cannot seem to get past Requirements. Ends do not justify any means, but Ends must be delivered.
9. Leave a record of what you have done, so the project will not miss you if you leave. If change is the only constant, then resources on a project will change. The risk in such change is that a person’s contribution to a project will be lost, and that the new person assigned to the project will have to start over. This is a particular risk in quick-and-dirty projects where an operating result is produced, but no one else can understand the code that was produced. However, if the contribution involves producing quality artifacts as described in No. 8 above, there is always a point-in-time record of what has been accomplished so far, which can be used by new project resources to continue the project with minimal disruption.
10. Models are better than text. It should be a goal for all of us in the IT business to adopt useful aspects of engineering to improve the quality of software, and modeling is a key concept to adopt. It almost frightens me that many still promote programming as an art form, that code can be beautiful or exquisite in some way. Well, even the most obscure art needs an audience to appreciate it, and it can’t just be other artists. Software is a product to be used, not admired, so if anything, programmers of the past 50 years have been more like craftsmen, using individual skills and experience to produce useful objects for society to use. The problem is that demand continues to outstrip programmer output (remember the backlog!), so improved, repeatable and transferable methods are needed to transform software development from a craft to a true industry.
11. Partition large projects into three-month phases. That is the longest period you can plan for without the chance of significant change to priorities, resources, etc. Once you have a detailed plan for three months, and a high-level plan for the rest of the project, you can add more detail to further target dates as the project progresses, as each interim target is reached or on a rolling month-by-month basis. The level of change in any three-month period will be manageable, much more than over the whole project.
There is a more recent corollary to the three month principle; the age of the mega-project should be over by now. Any IS project that takes many months or years to deliver the system is destined to fail. Yes, large systems are still needed, but break them into pieces that can be delivered, ideally about every three months; longer than that and you start to slide back to the mega-project approach, while shorter than that will not produce enough of the system to be worth delivering to the business. All business works in three-month quarter cycles anyway, IT should too.
12. Within the three-month phase, parcel work into two-week periods. Analyze for two weeks, then design and develop for two weeks (two developers), and then test for two weeks. When the first two weeks of analysis is done, start the next two weeks of analysis in parallel to the design/development; carry on in cascading two-week periods until the entire project scope has been addressed.
Are two-week periods too aggressive? I think not, based on experience. I find developers and a tester like to work in such quick bursts, as delivering more results faster makes anyone feel more productive and accomplished, and illustrate quickly what works and doesn’t work. However, small bits delivered quickly need to be integrated into an overall solution.
13. Given many medium to small software Deliverables, use Architecture to manage and integrate the Deliverables into a complete system. In Cascade, an Information System Architecture is used to integrate the two-week deliverables, until a complete deliverable (component, sub-system) is assembled.
In parallel, a release schedule is a great approach to support delivery. Gather the usable deliverables into timed releases that go into production together. As per Principle No. 11, a Release each quarter is recommended. The business receives what they are paying for often enough to be of value, but not often enough such that assimilation of change is so frequent it causes chaos.
David Wright is a veteran of over 25 years in the IT trenches. He started as a programmer in the mainframe-dominated 80’s, followed by 20 years as a Business Analyst and Architect in markets ranging from life insurance to express delivery to equipment leasing and financing. To order his complete book, Cascade — Better practices for effective delivery of information systems in a multi-project environment, visit http://www.lulu.com/content/2088656.
