The Community Blog for Business Analysts

David Wright
David Wright

Cascade - Day 3 - Principles

Like you, I have read my fair share of IT books and blogs, 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, etc.; the reverse is to document the new approach/method first and then describe what problems it fixes, etc.

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 what I am going to write 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, and I am a particular fan of the Business Rules Manifesto. 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 were 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 completetly whither in comparison.

So what are these new IT principles I propose?

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, resourcing, 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 all of the 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. ©

Next time, I will start to provide details on each Principle, starting (of course) with #1.

This entry was published on May 14, 2008 / David Wright. Posted in Systems Analysis. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  1 members liked this article

Related Articles


Only registered users may post comments.

Modern Analyst Blog Latests

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.


Copyright 2006-2024 by Modern Analyst Media LLC