MBA PREPS "PRIDE" METHODOLOGY PODCASTS

Aimed at eliminating confusion in Systems Development and IRM

PALM HARBOR, FL, USA (July 28, 2008) - In an unprecedented move, M. Bryce & Associates (MBA), the developers of the "PRIDE" Methodologies for IRM announced plans to produce a series of podcasts explaining the methodologies and how they work. "PRIDE" was originally introduced in 1971 as the first systems methodology in the indu ...

In this week's "Management Visions" broadcast, my essay is entitled "A CORPORATE POLICY FOR PERSONAL ELECTRONIC DEVICES" - Reviews the pros and cons of a new corporate policy on the use of personal electronic devices in the workplace.

My "Pet Peeve of the Week" is "Getting into a Rut," and we also have our "Letters to the Editor."

"Management Visions" is a weekly broadcast on subjects pertaining to Informatio ...

In this week's "Management Visions" broadcast, my essay is entitled "SOCIALISTIC MANAGEMENT" - Describes the pros and cons of the new "flexible management" concept.

My "Pet Peeve of the Week" is "Wearing Ties," 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 "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.