Cascade by David Wright by David Wright - Read Online

Book Preview

Cascade - David Wright

You've reached the end of this preview. Sign up to read more!
Page 1 of 1

them."

FORWARD – How will we document this? Start with Principles.

Like you, I have read my fair share of IT books, and each author has to decide how to best present what they are trying to communicate. One way is to describe the problems/opportunities of interest to the reader, then document the new approach or method that solves the problems; the reverse is to document the new approach/method first and then describe what problems it fixes.

I would like to try a mixture of the two, in the context of a set of Principles that I think will put all the content of this book in context. This is not an original idea, I must admit, as many manifestos and proclamations have been used to introduce new ways of things; the Agile Manifesto is well known (http://agilemanifesto.org/),and I am a particular fan of the Business Rules Manifesto (http://www.businessrulesgroup.org/brmanifesto.htm). These and others like them lay out the basic reasons for their existence and the value they provide.

Principles can be very effective; the best I have ever seen were created by Mao Tse-tung for the new Chinese Red Army after his first insurrection failed. His principals for protracted/attrition warfare was summed up in "a sixteen character military guide that even an illiterate peasant could understand…

Enemy advances, we retreat. 

Enemy halts, we harass. 

Enemy tires, we attack. 

Enemy retreats, we pursue."³

Effective words, against which I hope my own do not completely whither in comparison.

1. There is always more work to be done than people to do it.

2. Projects change the business, so know the overall business first.

3. Use an overall Architecture to describe the business, before and after projects.

4. Pick the right project(s) for the business.

5. Once a project is started, finish it.

6. Specialize – each member of a team assigned to a project should do what they do best for the length of that project.

7. One Architect/Analyst can generate enough work for two Developers and one Tester, structure your project teams in this ratio.

8. It’s the Deliverable (that matters), not the Task.

9. Leave a record of what you have done, so the project will not miss you if you leave.

10.Models are better than text.

11.Partition large projects into 3 month phases, which is the longest period you can plan for without the chance of significant change to priorities, resources, etc.

12.Within the three month phase, parcel work into two-week periods; analyze for 2 weeks, then design and develop for 2 weeks ( 2 developers ), and then test for 2 weeks. When the first 2 weeks of analysis is done, start the next two weeks of analysis in parallel to the design/development; carry on in cascading 2 week periods until the entire project scope has been addressed.

13.Given many medium to small software Deliverables, use architecture to manage and integrate the Deliverables into a complete system.

I consider these a work in progress so, like most inventors of new principles or practices, I have come up with an overall name to encompass them, for now and as they evolve. It is:

Cascade – Better practices for effective delivery of information systems in a multi-project environment. ©

Let’s look briefly at what each principle means or implies; which will serve as introductions to the remaining chapters that cover the principles in more detail.

1. There is always more work to be done than people to do it.

Bordering on glibness, this principle summarizes the reality of virtually all organizations and activities, not just Information Systems delivery. It implies that a group within an organization charged with delivery of end results will a have a back-log of work not yet done. The existence of such a back-log is in itself not a problem, it reflects the desire of an organization to solve new problems and actively improve itself; the problem arises when it grows perceptively in size from management’s perspective, and the length of time a change item sits on the back-log increases such that it can be measured in numbers of months or years.

So, 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.

A never-ending discussion in IT circles is about how much IT staff needs to know about the business that the information systems are supporting. It is high-lighted by every want-ad for an IT job that says previous experience in the employer’s industry is mandatory.

Is detailed industry knowledge⁴ and experience absolutely necessary for an IT job? No.

Can an IT staffer be effective with absolutely no knowledge of their employer’s industry? No.

As in many situations like this, the ‘Yes’ answer lies somewhere between the two extremes. Like a pendulum, the level of industry knowledge will vary across this spectrum, based on the specific organization, and by the particular IT role; e.g. Analysts need to know more than Programmers, and it justifiably argued that Testers need to know even more than Analysts.

So, 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.

The addendum to this discussion, however, is how much does IT need to know about the specific way their employer conducts business when competing in their industry⁵. Again from experience, I suggest that very little or no such knowledge is needed going into a project. The cliché that a little knowledge is a dangerous thing applies here. 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.

Do not fall victim to this belief. IT is about underlying hardware and infrastructure, and the information systems that run on them. The systems’ users and their