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

Principle #4 - Pick the right project(s) for the business.

At any one time, the IT department of an average company is running multiple projects. How did they get started? How were they even defined as a project that needed to be carried out?

No one may actually know. In more chaotic environments, projects can start as a seed of an idea, pick up momentum and resources if a manager or two can see that they will benefit from the project. At some point, the project will bump into another one, usually because they both want the same IT staff or other resources. Strong managers can often come out of these resource conflicts with what they need for their project, while the other managers suffer from their project going on hold or being cancelled. Otherwise, the conflict is escalated until one ...

Principle #3: Use Architecture to describe the business, before and after projects.

“Architecture” is becoming a more widely used term associated with Information Technology. The number of adjectives applied to the term seems endless: “Technical Architecture”, “Systems Architecture”, “Business Systems Architecture”, “Enterprise Architecture”, and so on, so it must be important.

Why do we need Architecture?

Architecture is not an end in itself; Architecture exists because things need to be built.

Architecture is required when building anything that is not simple; in its essence, Architecture identifies all the separate components of an end product and how all the compon ...

In this week's "Management Visions" broadcast, my essay is entitled "WHAT YOUNG PEOPLE WANT & NEED" - Discusses the need for "Parenting Management."

My "Pet Peeve of the Week" is "Having it Your Way," 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 availab ...

In this week's "Management Visions" broadcast, my essay is entitled "WHY WE RESIST PLANNING" - Discusses the reasons why people do not like to plan.

My "Pet Peeve of the Week" is "Signatures," 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: RealMedia (RM) a ...

Hi:

I am cjmemphis, the author of this blog, and I seek to network with Business Analysts, Project Mangers, Developers, Data Analysts, and hopefully Business Users of the products we deliver. 

Its my intention to work with willing participants of the above parties, to improve the process of delivering highly effective work products to our employers, clients and customers. 

Currently, we are looking at the requirements gathering process and are asking the following question:  What 2 or 3 circumstances have you experienced in a project or organization that constrains or hinders you from producing less than optimum business requirements?  When I say 'less than optimum', I am referring to your personal perspective of the requirements, not necessarily the organization's views of them.

Please let me know your thoughts and lets engage in some dialogue.  Together, each of us c ...

In this week's "Management Visions" broadcast, my essay is entitled "WHY I.T. STANDARDS FAIL" - Discusses the reasons why standardization fails in the Information Technology industry.

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

In this week's "Management Visions" broadcast, my essay is entitled "CHANGE: WHAT LIES AHEAD?" - Describes the three agents of change for the years ahead.

My "Pet Peeve of the Week" is "Financial Talking Heads," 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 ...