In this week's "Management Visions" broadcast, my essay is entitled "THE BENEFITS OF A SYSTEM AUDIT" - Describes the need for reviewing the results from a systems project.

My "Pet Peeve of the Week" is "Office Meetings," and we also have our "Letters to the Editor."

"Management Visions" is a weekly broadcast on subjects pertaining to Information Resource Management (IRM). It is available in the following file ...

In this week's "Management Visions" broadcast, my essay is entitled "CURRENT SYSTEMS ANALYSIS" - Describes the rationale for documenting existing systems.

My "Pet Peeve of the Week" is "Super Bowl Ads," and we also have our "Letters to the Editor."

"Management Visions" is a weekly broadcast on subjects pertaining to Information Resource Management (IRM). It is available in the following file formats: RealMed ...

I am now lucky enough to be working at a consulting company with a great group of experienced people, and we do share some great "war stories", and it made me think that I do have my share of experiences that, if written down, some small number of people may find interesting.  Seems to me a blog is great for that.

I would call this memories rather than a "memoir"; the latter would imply I have spent time researching myself and might, for example, be able to name all the people I went to school with or have worked with over the last 3 decades; not gonna happen. People who write Memoirs were also usually prescient enough to keep a diary or journal since a young age, but not I.

But, I don't think anybody will be checking my facts or lack of them; and as a blog, any reader of a certain age who wants to chime in is most ...

Thirteen is all you need, at least in this point in time. I may add to them as time goes by, but I would also like to hear from readers if they have any suggestions or thoughts or their very own principles for IT Projects success. Pleae offer them and maybe we can get them into the second edition of the book...which you all remember is available at http://www.lulu.com/content/2088656 .

In fact, if (and its a big if) I get a number of suggestions, I will judge which one to be the 'best' of the bunch; winner gets a free copy of the book.

And to get things going, a free copy of the book also goes to the first person to submit a suggestion, so be quick!

David W. Wright

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

This is a more specific statement of Principle #3; 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 #11, a Release each quarter is recommended. The

In this week's "Management Visions" broadcast, my essay is entitled "IMPACT ANALYSIS" - Describes a technique for managing changes to systems and software.

My "Pet Peeve of the Week" is "A Day at the Beach," and we also have our "Letters to the Editor."

"Management Visions" is a weekly broadcast on subjects pertaining to Information Resource Management (IRM). It is available in the following file formats: Re ...

12. Within the three month phase, parcel work into two-week periods; analyze for 2 weeks, then design and develop for 2 weeks (two 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.

OK, a 64 word-long paragraph is pushing the boundary of a ‘Principle’, but this point is the basic building block of Cascade. 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 illustrates quickly what works and doesn’t work. However, small bits delivered quickly need to be integrated into an overall solution, which leads to Principle #13.

In this week's "Management Visions" broadcast, my essay is entitled "SYSTEM DESIGN BACKWARDS" - Describes a system design technique that promotes design correctness.

My "Pet Peeve of the Week" is "Walmart," and we also have our "Letters to the Editor."

"Management Visions" is a weekly broadcast on subjects pertaining to Information Resource Management (IRM). It is available in the following file formats: Rea ...

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

I was lucky to learn this early in the 90's as Project Management was getting a higher profile, accompanied by the increased use of Microsoft Project. Other PM tools were in use, but usually in limited numbers; MS Project, on the other hand, was readily available and budding Project Managers thought they could now plan the whole world for months or years in advance.  What actually happened, however, was constant re-planning as the reality of business change and resource turnover always took their toll. As Napoleon said, "A plan is only good until the battle is joined." After that, one must adapt to the changes that will always come.

#10. Models are better than text.

I would like to think that by this point in time, this principle no longer requires justification. It has been at least a few years since I last saw a dense “SRD” or “SDD” document (SYSTEM REQUIREMENTS DOCUMENT, SYSTEM DESIGN DOCUMENT).  I must offer my respect to the many talented people who labored to produce these documents over the decades; these documents were at least a step up from no Requirements or Design artifacts at all.

Consider what a ‘model’ really is in general; it is a representation of a finished product in a scaled down version; engineers have been literally creating models of what they are going to build for centuries, for such reasons as testing out problems on a small scale, and for presen ...

In this week's "Management Visions" broadcast, my essay is entitled "STEPWISE REFINEMENT" - Discusses the concept of decomposing objects in order to manage complexity.

My "Pet Peeve of the Week" is "Being Sick," and we also have our "Letters to the Editor."

"Management Visions" is a weekly broadcast on subjects pertaining to Information Resource Management (IRM). It is available in the following file formats: ...

#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 principle #8, 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.

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

The final deliverable is the Information System ready to be used effectively by the Business. If you can jump from ‘Start’ to this final deliverable in one “Task”, then power to you. Some people can do this; most cannot. This is again where a team of specialists is most effective on an average project.

This means that the project work will be divided into many tasks, sub-tasks, etc. . . . 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 expla ...

#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.) This ratio combines with the specialization of principle #6 to form the strong basis for the Cascade effect covered in the last principle to come.

I will be using the most common ‘role titles’ of analyst, designer,

In this week's "Management Visions" broadcast, my essay is entitled "WHEN YOU HIT A WALL, GO AROUND IT" - Use your head for something other than banging into a wall.

My "Pet Peeve of the Week" is "Finding Jesus," and we also have our "Letters to the Editor."

"Management Visions" is a weekly broadcast on subjects pertaining to Information Resource Management (IRM). It is available in the following file formats ...

This principle supports #5. 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 producti ...

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.

However, trying to run too many projects at once ends up pleasing no one, as no project makes any noticeable enough progress to be seen as a success, so the result is that no one is happy with IT’s performance.

So, project ...