David Wright is no stranger to many who participate in the various online business analysis-related forums and online communities. He’s been in the business for over 25 years and, during that time, has accumulated quite a bit of practical knowledge and insight.
Not long ago, he decided to put pen to paper and share some of that accumulated knowledge in Cascade; a guidebook using a framework of 13 principles to describe “better practices for effective delivery of information systems in a multi-project environment“.
I’ve read and enjoyed the book myself, and thought it’d be interesting to get a little background on Cascade and the thought process behind it.
With that in mind, I sent David a list of questions that you’ll find below along with his responses and a few of my own comments on the book.
Cascade is a pretty unique title. How did you come up with that?
It’s a play on Waterfall methodologies. I always thought Waterfall was a misnomer, because of the standard criticism of it being slow; I have been to Niagara Falls a few times, and it has never looked slow. A “cascade” is usually visualized as a small but very quick moving thing, and it just clicked with me when I was looking for a high-concept name for what I was writing about.
What motivated you to write Cascade? What are your goals and aspirations for it?
It was something I had to get out of my head and down on paper (or Word doc). I have been working in information systems long enough that I had a set of “rules of thumb” that helped me be successful while avoiding failures I have seen before. I was having a conversation one day with a friend about methodologies and manifestos and what they really accomplished, and it dawned on me that my own experiences and “rules” addressed the same topic. It took me about a half-hour to write out the first cut at what would become the practices in Cascade. After that, it was a matter of fleshing it out with examples and war stories. I guess it comes to that old adage of writing about what you know.
My goal now is to share Cascade with any and all who might find it of interest, and who might be helped by it. To be honest, I did not think about this much while I was writing it, I just needed to get it written. It is a vast marketplace of ideas out there, so achieving that goal is the challenge now; writing it was the easy part!
The book specifically addresses multi-project environments. What caused you to focus there?
It is the reality that most any IT shop faces, but when you want to find some methods to help deal with that reality, what you will find most in the market is methodologies that describe how to best deliver a single project. Most of the time in my career I would be working on several projects at the same time, reflecting the fact that the IT departments I worked in were always executing many projects at the same time. There was never the luxury of doing one project at a time, get it done, and then start another one. There are always too many demands on IT from all parts of the rest of the business to allow that. So constantly working in that environment lead to the experiences that drove out my rules and practices.
There are lots of good practices when it comes to IT delivery. Just curious, how did you whittle the number you addressed to the 13?
It was actually built up to thirteen. I started with my initial draft list, and added a few more to address certain experiences, and it settled down at 13. Anything else I wrote after that fit into one of the thirteen. At this point, I like the number itself, at least for now. I am still working on projects every day, so I may have some more practices to add down the road.
Who would you say would benefit most from reading it?
I would like to think that almost anyone involved in multiple projects at a time could find some benefit, from project sponsors through to testers. I suppose the main audience is IT Managers who are responsible for a group of projects, or manage the people who work on many projects. Most of my actual work over the years has been in Business Analysis with some Project Management when needed, so that’s in there too. The idea of the separate practices is that you only need to read those that affect your work the most, then hopefully readers will take in the rest after that.
What about Cascade are you most proud of or has given you the most satisfaction?
As a Business Analyst, I have done a lot of writing over the years, but always for a project purpose: Project Charters, Business Cases, Requirements Documents, and so on. Cascade is something I wrote for myself, no methodology or templates or standards to drive what I wrote. So, seeing it done was a moment of pure pleasure of accomplishment. I had never pictured myself as an “author”, so to be one now is a good feeling, I highly recommend it to anyone who thinks they might have it in them.
My Thoughts?
First of all, I appreciate David taking the time to respond to my questions, and enjoyed reading the responses. I hope you did, too.
As I said above, I read Cascade and really enjoyed it. It was a quick, 100 page read with a light, familiar tone and a nice pace.
I wouldn’t say David has invented any new principles or coined any new buzzwords with Cascade, but he does provide some specific and sound advice on how familiar principles can be put to good use in a multi-project environment.
I think it’s a good resource and I do recommend it to business analysts particularly for the useful way it ties principles of business analysis in with architecture, project management and resource management principles.
Availability
Cascade is available at Amazon and other various online booksellers. If you’d like to get more acquainted with David, look him up on Twitter or check out his blog (which contains quite a few Cascade teasers if you look back through the archives).
Have you read Cascade? If so, what were your thoughts? What other recently-released books would you recommend as a good read for BA’s?
Read it, liked it and keep it on my desk at work. That should tell you something right there. It’s a good read and well worth a new look at an old problem. Thanks to you both for reviewing it….now I have to go read it again.
Well said, Doug!