PM World Today Letters To The Editor

Warren Allen on the Software Development - Business Requirements Communications Gap

Warren

Max Wideman suggests that the Communications Gap that you spoke of in your Letter to the Editor was "A Software Architect" Function that was a book review in the PM World Today January 2003 Issue. See http://www.pmforum.org/pmwt03/publications03-1htm

David Curling http://www.pmforum.org Email curlingd@loday.com

Warren Allen replied...

Thanks for the reference and I read the review. I agree that the concept of the "Software Architect" that is the subject of the book addresses, at least
in part, the same basic problem that I was referring to as the corporate Communications Gap.

However, I would like to see the concept applied within the structure of a large organization as an integral part of the way that organization does business. I would envisage a staff group of experienced professionals, reporting to the CEO or COO and having access to and involvement in all major change projects across the organization. This group would in fact provide the "project management" services needed to plan and implement these projects. They would be involved in organizational change projects, special marketing programs, infrastructure development projects, acquisition anddivestiture projects, organization analysis and evaluation projects, new facility and facility upgrade projects, etc, etc, ........ and software development projects.

Large organizations are in a constant state of change in a lot of ways in which any new software development is only a small part of the full scope of the change project. This new staff group would have the experience, skills and authority to effectively coordinate this ongoing change project process and to enhance the chances of project success.

As for software development projects...... Specialists within this group would be assigned to manage large software development projects.Their primary function would be to manage the requirements and expectations of the user/operator and to manage the work commitments, promises and performance of technical resources, whether they be internal or external, needed to design and implement the project, . i.e.. these guys would act as"Software Project Managers". In Max Wideman's world, there may be the need for a "Software Architect", but if so this individual would probably be drawn as a senior staff member from the IS group, and would report to the "SoftwarePM".

My real problem is that so far, I haven't been able to convince any CEO or COO of the need for this kind of function within their organization. Unfortunately, proving the cost effectiveness of this approach is difficult to do without the experience of having done it at least once.

Warren Allen warren.allen@shaw.ca

A Comment by Warren Allen on the May 2003 Editorial - Why Don't Software Methodologies Work ?

I don't believe the unsuccessful performance of IS Projects should be laid at the feet of any particular project methodology. Most IS methodologies that I have seen have the basic ingredients of a reasonable project management system, and sufficient flexibility to be made to work in any particular project situation. The problem is that, for some inextricable reason, they seem to encourage, or at least allow, the project managers to stop thinking and to simply follow the methodology by rote until it is obvious to everyone that the PM systems aren't working.

I would suggest that the fundamental reason for IS project failures is because of a huge and yet unidentified Communications Gap that exists between the IS techies who are typically assigned project management responsibility, and the line managers who have the responsibility for defining the requirements of the new system.

These two groups spend a lot of time talking with each other in the planning stages of the project. However, the teckies use words and describe concepts that they think is being understood by the other side, but aren't. And the operators hear system concepts and project deliverables that they think they understand but they don't. Because of the complexity of the project scope, the operators very quickly end up abdicating their responsibilities to the teckies with the frightening result that the techies are allowed to make countless command and control management decisions without operator knowledge and or approval. And when the reality of the new system begins to take shape so that the operator can then begin to see just how it will be applied to his area, he begins to realize that it's not what he thought he was getting or even if it is, it just won't do a proper job. And so begins the end cycle of scope revisions, extensive time delays and increasing costs.

This Communications Gap exists in virtually every major organization that I have looked at or been a part of. And the result of this situation is that many large organizations are really out of control in terms of the line management's understanding of what the organization's many computer systems are doing or not doing to impact on the basic decision making process in the organization.

I believe there is the need for a new "hybrid professional group" to be established in most large organizations. This group would act with the authority of the CEO or COO of the organization and would have the project management responsibility for all "soft projects" undertaken by the organization. This would include IS development projects, as well as a multitude of other change projects that are becoming increasing a part of the organizations culture. This internal management consulting group who include professional resources with experience and training on both the IS and operating side of the organization, and with addition demonstrated skills and experience in project management. This high powered group of professionals would be assign PM responsibility at the very beginning of any software development project and would be accountable for project delivery and results. Their resource teams would be drawn from both IS and operating units, as well as external resources. All would be assigned and accountable to the PM.

In the rapidly changing environment of today's large organizations there is the need to somehow "institutionalize" the change process within the entities' formal organization. With this kind of internal project management group established in an organization, whatever software development methodology is adopted by the organization would be made to work and to produce success results. These guys would have the effect of bridging the Communications Gap; making sure that the operator really understands what he's getting; making sure that the techie really understands what's needed.

This solution is a very hard concept to sell in most large organizations because the Communications Gap that I speak is rarely if ever acknowledged as a serious problem by either IS or operating folk!! What a dilemma......................

Warren Allen warren.allen@shaw.ca

Ken Ganshirt Comments on the PM World Today May 2003 Viewpoints Column

In Mr. Alleman's "Viewpoints" column titled "Project Management
Herding Cats" he begins by stating he has an issue with "...folks
who start with the premise that project management processes are
performed separately from the management of software development
processes. ... This provides them with the comfort of discussing
project management in the absence of any specific business terms."

Mr. Alleman appears to misunderstand the point of such discussions.

If one is to determine whether there is a discipline of "project
management" at all one must first determine what, if any, roles,
functions, activities and/or processes distinguish "project"
management from "functional" management. I believe that over the
past few decades it has been satisfactorily established that there
is a case for such a discipline and generally what it consists of.
Most who consider themselves at least marginally knowledgeable on
the subject feel they have moved beyond the question of whether
project management exists and what it consist of to "how can we do
it better?"

The point of discussing project management activities and processes
independently from (not "in the absence of") the functional
management activities, roles and processes is to understand the
project management function better in order to find ways to perform
it better.

Mr. Alleman goes on to say: "Sort of like talking about accounting
in a classroom setting, when what I'm interested in is applying
accounting to a specific business problem."

If Mr. Alleman enters a classroom that is publicly scheduled for a
class in general accounting principles, does the fact that Mr.
Alleman isn't interested in learning general accounting principles
make the Prof wrong for teaching it in its alloted time slot? Or is
Mr. Alleman simply in the wrong classroom? It seems he wants to be
in the workshop on applied accounting practices.

Both knowledge sets are required, but it's not an "either/or"
question. It might be reasonably argued that you need at least a
basic grounding in general accounting principles before you can
expect to become proficient at applying them to any specific
business problem. One does that by first identifying the underlying
general principles, understanding them, and refining them. Only
then can you expect to successfully apply them to specific
situations, in my opinion.

Finally, Mr. Alleman says "Many consider the management of software
development to be a 'product development methodology.' While nearly
universally, software development managers consider their role of
managing the activities of developers and the delivery of software
products to be 'project management.'"

I think Mr. Alleman's confusion .. or the confusion of the rest of
the project management community .. stems from the fact that new
software development -- unlike almost every other business activity -
- has almost no existance outside of a "project" context.

The development of new software is not a core business activity for
any but a few businesses, and fewer government agencies. Obviously,
software development companies; less obviously, companies which
manufacture components with embedded software for telecommunications
equipment, automobiles, entertainment equipment, some household
appliances and so on.

New software development as a core business function is still very
much a niche activity in the larger context of business and
government in general.

The greatest majority of business functions exist, day to day,
outside of a project context. Projects are exceptions to the normal
conduct of their everyday activities. Sales departments have
selling to do. The accountants have beans to count. The Shipping
department as stuff to ship. The assembly line may have software
controls, but on a daily basis it runs nicely without new software
development. And so it goes.

This is also true in the Information Technology (IT) department.
Even here the folks who develop new software have become the
exception. Most of the IT department is occupied with the jobs of
keeping the [soft and hard] computing infrastructure of the business
operating, increasingly in a high availability mode. It might be
reasonably argued that they could do this even more effectively if
they did not have the distraction of new software development to
deal with.

In the day to day business of business and government, nobody has
any great difficulty identifying that to do a project successfully
there are roles, functions, activities and/or processes that don't
occur at all, or at least not in the same way, as when you are doing
your everyday work activities. That, indeed, impinge on your
everyday work acitivities and, therefore, need to be handled
professionally and in a way that allows the day to day business of
business to continue while still using many of the same resources to
conduct the project.

In that context, most functional managers and project managers have
no difficulty discussing the roles, activities, functions and
processes of project management independently from those of
functional management.

But in the niche of new software development activity we have a very
different situation. New software development -- in an organization
which does not do software development as a core business function --
only exists in a "project" context. That is, in order for there to
be a demand for new software development, there first has to be a
requirement to change how some part of the business wishes to
function, and a subsequent requirement for new or changed software
as part of the solution.

Since "project" work is almost the only driver for new software
development, it is easy to understand why many functional managers
whose job is to create and deliver new or changed software view
their roles as "project management" rather than functional
management.

This results in interesting debates in the IT community over whether
it is more effective to view their work as "functional", develop a
method for doing that work, and then wrap an overarching project
management methodology around it (or fit it into the more general
project management methodology which might be in use in the
organization), or whether it is more effective to tightly integrate
the "functional" and "project" management activities into a single
methodology.

Mr. Alleman is clearly in the latter camp. Unfortunately, he
appears to completely dismiss even the intellectual value of
discussing any other possible scenario.

By failing to understand, or simply dismissing, the value of
identifying, understanding and discussing the underlying principles
of project management independently from functional management, I
think Mr. Alleman does a disservice to the project management
community. And to the IT community.

For the record, I am an IT professional of 28 years. I began my
professional career as a new software developer and have worked as a
developer, designer, technical analyst, business analyst and
functional manager both inside and outside of IT.

Ken Ganshirt
email address: ken_ganshirt@yahoo.ca

Bill Duncan Comments on the PM World Today April 2003 Editorial

Mr. Alleman's "Viewpoint" could easily cause the casual reader to misunderstand the
view of project management as it is described in "A Guide to the Project Management
Body of Knowledge."

In his second paragraph, he mentions "folks who start with the premise that project
management processes are performed separately from the management of software
development processes. ... This provides them with the comfort of discussing project
management in the absence of any specific business terms."

Conveniently, Mr. Alleman never identifies who these "folks" are, but later in the
column, he refers to "PMBOK-style project management." One could easily assume
that these "folks" are "PMBOK-style" project managers.

In fact, "A Guide to the Project Management Body of Knowledge" is quite explicit
about the linkages between the product-oriented processes and the project
management processes. I quote: "Project management processes and product-
oriented processes overlap and interact throughout the project."

As well, there are numerous other instances throughout the document where specific
and explicit reference is made to both these interactions and to the importance of
understanding and managing the business issues involved with a project.

If these "folks" that Mr. Alleman refers to behave as he describes, then they have
misunderstood and misapplied the guidance that the document provides. Mr. Alleman
and the PMFORUM do the profession a disservice by publishing such a carelessly
worded piece.

Name: William Duncan
Company: PM Partners
email address: wrd@pmpartners.com