Cascade #4 – Principles for improving IT Projects


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 am using a mixture of the two, in the context of a set of Principles that 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 (,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.


So what are these new IT principles I propose?


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


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


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


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


  1. Once a project is started, finish it.


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

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


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


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


  1. Models are better than text.


  1. 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.


  1. 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.


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


 In Cascade #5 we wil start looking at each Principle.

Related Download
CanadianCIO Census 2016 Mapping Out the Innovation Agenda Sponsor: Cogeco Peer 1
CanadianCIO Census 2016 Mapping Out the Innovation Agenda
The CanadianCIO 2016 census will help you answer those questions and more. Based on detailed survey results from more than 100 senior technology leaders, the new report offers insights on issues ranging from stature and spend to challenges and the opportunities ahead.
Register Now