Technology's Influence On Organisations.

The answers from these project managers led Shenhar to identify three levels of technical complexity within the projects under the scope of their responsibility:

  - Level 1:  Assembly.  This is a project consisting of a collection of components and modules combines into a single unit.  A typical assembly may perform a well defined function within a larger system, thus constituting one of its subsystems.  Alternatively, it can be an independent, self-contained product that performs a single function;

  -   Level 2:  System.  This represents a project consisting of a complex collection of interactive elements and subsystems within a single project, jointly performing a wide range of independent functions to meet a specific operational mission or need;

  -  Level 3:  Array.  This represents a program, rather than a single project, where program is taken to mean a series of related projects designed to accomplish broad goals and to which the individual projects contribute.  Often, arrays are dispersed over wide geographical areas or over an extended period of time and consist of a variety of project systems.

Is it stretching things, or do Shenhar’s levels of complexity within projects somehow echo Joan Woodward’s levels of complexity within organisations?  While the two performed their studies 30 years apart and, it may be argued, in worlds now far apart, to me they seem remarkably similar.  Consider the following comparisons:

Shenhar’s “Assembly” - Combining components to make a single unit.

Woodward’s “Unit” - Producing custom-made products (nearly single units) to customer specifications (consider ‘specifications’ as ‘components.’)

Shenhar’s “System” – Collection of interactive elements performing independent functions to meet a specific need.

Woodward’s “Large Batch/Mass Production” - Use assembly-line production methods (each station on the assembly line works simultaneously with the other stations - interactive elements?) to manufacture large quantities of single products (the end product that is being manufactured - a specific need, or end goal, perhaps.)

Shenhar’s “Array” – A group of related projects designed to accomplish broad goals.

Woodward’s “Continuous Process” - Use continuous flow processes (consider processes are projects) to process raw materials (here, the contribution of individual projects plays the role of raw materials here) into finished products (broad goals).

If the reader feels the above comparison too abstract, it still should not damage this paper’s central argument.  For following are many (less creative) similarities between complex organisations and complex projects.

 

Classifying Project Content In Terms of Technical Complexity

Historically, classifying projects themselves was done by grouping them by industry or business sector.  This proved unsatisfactory as most all industries are involved with projects that might be identified as belonging to other industries, such as construction or research and development.  A project’s technical complexity also can not be confined by industry boundaries.

Herein lays the problem in categorising projects.  What is needed is a classification independent of industry, one that brings together project management commonalities while differentiating between areas of project management applications.

Shenhar accepted this challenge in 1993.  He asked managers to rate their projects according to their level of technological ‘uncertainty,’ which they believed developed directly from the technological complexity of their projects.  Shenhar discovered four main types of technology content within projects:

  -  Established Technology or Low-Tech:  Projects rely on existing and well-established base technologies to which all industry players have equal access;

  -  Mostly Established Technology or Medium-Tech:  Similar to Low Tech, except that the projects in this category involve some new technology or feature that provides market advantage and a higher degree of uncertainty;

  -  Advanced Technology or High-Tech:  There are projects in which most of the technologies are employed together for the first time.  However, the individual technologies already existed prior to the project’s initiation; and

  -  Highly Advanced Technology or Super High-Tech:  These projects are involved with emerging technologies (those not entirely existing, or still in R&D) and/or technologies unknown at the time of project initiation.  Project execution therefore involves technology development, testing and selection from among alternatives.

Many others have examined the concept of ‘uncertainty,’ as it grows along with technical increases.  Winch, however, observed something else about uncertainty:  It varies at different points in a project’s lifecycle.  He astutely points out that the level of uncertainty is very high in the early stages of the project’s lifecycle and progressively reduces to zero at project completion.

Winch goes on to describe the size of a project in the same manner, claiming it also changes along the course of the project.  A project, he says, is started by a few very highly skilled people, and will mobilise much larger numbers of less skilled people once on site.

 

Looking at uncertainty another way, Winch nicely ties together the Mintzberg and the Matrix.  “The basic tenet of designing effective organisations is that organisations facing high levels of uncertainty need to be relatively adhocratic in organisation, and can not be large, while organisations facing lower levels of uncertainty can be both relatively bureaucratic and large.  This shift in project organisation is known as matrix swing, typically occurring around 15% of the way through the project.

In the fray is another author, J. Williams, who notes that the complexity of projects has been increasing continually since World War II.  Williams says there are two compounding causes for the increasing complexity within projects that are particularly worth noting:

  -  First, the products being developed today are increasingly complex themselves, which leads to more complex projects.

  -  Secondly, projects have tended to become more time-constrained, and the ability to deliver a project quickly is becoming an increasingly important element.

One of Shenhar’s most interesting research queries was his attempt to relate project success to the level of technical complexity in a project.  First, he had to define what he meant by “success.”   From questionnaires sent to project managers and quantitative data collected on more than 100 projects, he determined that project success could be defined in four primary categories:

-  Internal Project Objectives:  Efficiency during the project;

-  Benefit to Customer:   Short-term effectiveness;

-  Current Contribution:  Medium-term effectiveness; and

-  Future Opportunity:  Long-Term project effectiveness.

Having ‘defined’ quality for the purpose of his inquiry, Shenhar next sought some correlation between the success criteria above and the technological content of projects.  And indeed, he learned that the different categories of success actually varied with technological uncertainty.

Specifically, the importance of meeting time and budget constraints reduced with increasing technical complexity, while the impact the project had  on the customer increased when moving from project of established technology to projects of higher technology, i.e. those of higher uncertainty.

Must Management Change For Complex Projects?

Does it follow that project management must also change as the content of the projects become more complex?  There are some, albeit few, who reject the idea.  The argument goes something like this.

While the choice of organisational structure will depend upon factors such as size, content and complexity, projects within the organisation are a function of the capabilities of the individuals rather than the way in which they are organized.  Talented personnel will perform well in most project structures and much better in a well-organized project.  However, poor talent will always do an inferior job, irrespective of how the project, or organisation, is structured.

Professor Nigel Smith, Dean of the Faculty of Engineering at The University of Leeds in England, seems to believe similarly.

  “The quality of the performance of a project is greatly dependent upon the quality of the project’s staff.  Great attention must be paid when selecting staff, as they continuously direct and communicate with others.  “Personality and the ability to think ahead are as important as technical know-how.”

Many other researchers beg to differ, however, and believe that project managers must change their approach in order to effectively manage projects, project that have become larger and more complex with each passing year.  “To effectively deal with an ever-shifting business environment, rapid technological change and stiff global competition, not only do organisations need to change their approach to doing business, managers must change their approach to managing projects, says one.

 “Additionally, global organisations require even further collaboration across numerous cultures and time zones.  While the projects are getting more complex, the margin for error is shrinking.  In today’s environment, project managers need to assure top management of a clear and strong return.”

New Solutions For Managing Complex Projects

The need for fluid methodologies has been acknowledged by project management professionals since the 1950s.  Consider the evolution of models appropriate to some changing dominant project characteristic during the past four decades:

In the 1960s        There was ‘scheduling’ for keeping control of simple, certain projects;

In the 1970s        Project managers relied upon ‘teamwork’ to integrate complex projects components and functions;

In the 1980s        Importance was placed on ‘flexibility’ for reducing uncertainty within complex, highly technical projects; and

In the 1990s        ‘Simultaneity’ or dynamism was the approach for complex, uncertain and quick projects.

Thus, it is not surprising to note the addition of other, newer organisational structures and technical tools as we approach the middle of first decade in 2000.  Below, this study divides a few of the most significant into two categories:  Organisational structure, where researchers seem to look first, thanks to Joan Woodward, and computer programs and models.

New Organisational Structures

We have seen how traditional, functional organisational structures were simply the wrong environment for project managers.  Its shortcoming led to the matrix design, an organisational arrangement based on two overlapping bases of departmentalisation (e.g., functional departments and product categories), wherein employees are members of both their own departments and a project team under a project manager.

Given, matrix structuring did, and in some ways still does, improve organisational flexibility and provide an efficient way for a company to use its people. One of the biggest criticisms of the matrix, however, is that such organisation also leads to uncertainty about reporting relationships and may cause additional time in project coordination.

It wasn’t long, therefore, before researchers and practitioners alike were again re-inventing organisational structure to better aide managers in keeping hold of larger, more complex and more technical projects.   “The core of project management lies … with the establishment of an organisational function that is concerned with the delivery of the system to the client,” said one.

Paul Gaddis was the first to look to identify the implications of this organisational innovation, characterizing the project manager as the ‘manager in the middle.’  

“The project manager can be neither an expert in the domain of resource bases, nor the client as such.  The role of the project manager is to act as the interface between the client’s desires and the capabilities of the resource bases – to sit at the interstices of the project coalition matrix.  The project manager performs the role in complex projects that neither the client’s own functional managers, nor the managers of the resource bases can achieve – the coordination of the project so that it fulfils the client’s business needs.

By the mid-1990s, there began a move back to flatter organisation structures.  Just such a ‘flatter’ structure was the establishment of a Project Management Office.  The project management office has received a great deal of attention from researchers, and it appears likely it will remain a part of the future for project management.  Its implementation so far seems to best benefit larger or global corporations, where at any given time there are several big, highly complex projects commencing simultaneously.  

One surprising result from the study performed by The Center For Managing Business Practices seems to show that the project management office is no passing fancy.  As of Q4 2002, a full 44.6% of the surveyed companies (in the U.S.) had an established project management office, or a center of operation for project managers and project management.

This office is a relatively flat and agile team that creates a project-centric mindset using formal management methodologies and tools.  For some organisations, such offices provide the rigor necessary to ensure success amid the many forces that often undermine project efficiency.

Before describing the Project Management Office in detail, this study first would like to introduce Winch as the light under which the project management office’s role within an organisation might be examined.

Winch speaks of the range of applications of the project management concept across a number of industries and notes that the differences seem to depend upon whether the resource manager or the project manager has more control over the project.  He describes four types of organisations where this factor differs:

  - Functional Organisation.  Here the resource manager has complete control and the project manager plays little more than a liaison role.  There is no attempt at lateral co-ordination.

  -  Lightweight Project Management.  The project manager has clear responsibilities for overall co-ordination, monitors progress and brokers competition for resources.  In the end, however, he continues to be reliant upon the resource manager for resource allocations to the project.

  -  Heavyweight Project Management.  The converse of the above, the project manager holds the stronger hand, overriding resource allocations made by resource manager.

  -  Cell Organisation.  The project manager has complete autonomy.  Cells often have a light covert aura, as others in the same company may know little or nothing about the ongoing project.  Such cells are necessary in companies engaged in, or supporting, secret military or investigational efforts.

Now consider the development of the Project Management Office.  Because the concept is new, the charter of a project management office continues to evolve.  It can be all or part of each of the following:

   -  A Support Office, which, upon request from project managers, provides anything from administrative support to research, information and communications, resources and materials.  In this environment, Winch’s ‘Heavyweight’ might be the project manager’s role.

  -  A Monitoring Office, which keeps tabs on all the corporation’s ongoing projects.  In this capacity, the project management office may provide assistance when projects hit barriers or suffer formidable setbacks.  Or, it may issue alarms when costs, deadlines and other goals are not being met, and enquire how it may be of service to the project manager so he can get his team back on track.   In this organisation, we might find Winch’s Lightweight Project Manager.

 -  A Governing Office, from which all projects are generated and to which all project managers report.  This office also sets budgets when allocating the projects to different managers.  Additionally, project managers leave the evaluation of their projects to this office, which is responsible for conducting the final analysis of all the company’s projects for the CEO or president.  Here of course, we find Winch’s Functional Organisation.

Such a structured approach may not be necessary or appropriate for every organisation.  Nonetheless, it shall be interesting to watch the evolution of the project management office during the upcoming decade.

Computer Software and Modelling

Responses in the study performed by The Center For Managing Business Practices revealed that the two most commonly implemented project management improvement initiatives are software tools (77.4%) and methodology development (69.1%).  Companies that implemented project management improvement initiatives spent an average of $712,000 (U.S. dollars) on them annually.

Computers have rocked the world in the past two decades, and their effect has had as significant an impact on the world of project management as any other.  In the meantime, there also has been increasing commercial pressure for project managers to achieve predetermined time and cost targets.  This, too, has led to a proliferation of project management software packages.

Project management software programs vary widely, but all are designed to serve the same purpose:  To provide project managers with the power to plan the time and cost out-turn of their projects.

The marriage of computer programs to project management purportedly began in the late 1960’s, when the U.S. Navy was trying to figure out how to tackle the gigantic Polaris project.  Polaris’ mission:  To create a missile that could be fired below water, then fly through the air to its destination.  Those in charge employed a West German computer program called PERT to control the program’s many facets.  The project … and PERT … were a big success, and news spread quickly.

There are those today who still assert, “At the very least, a good project management software package [will] support probability analysis via PERT, [which] allows the definition of optimistic, most likely, and the most pessimistic durations for activities, so the probability of completing a project within a given timeframe can be ascertained.” 

However, the ‘latest’ software usually is obsolete almost as soon as it appears on store shelves, for there is always another under development, or already completed, that soon will take its place.  It is likely that PERT will continue to fade to the background, replaced by software that does the same thing and more.  Likely, it also will be easier to use and more dependable.  The same holds true for CAD’s three dimensional modelling.

   

Computer software is a dry subject, something of a yawn for those not in the field.  Rather than provide the excellent detail given by Winch, this study will, for your benefit and mine, give a light overview as given by Smith.

Program management software today links time, cost and resources of a project, and allows the project manager to forecast expenditures and to assess a range of scenarios that reflect likely change and uncertainty.

Williams developed a new computer modelling tool that enables the project manager to model the behaviour of complex projects.  Primarily used for risk management, Williams’s program elicits information from project groups and analyzes the structure of causality to gain understanding of the dynamics in “messy” situations.  The builds models and evaluates the cause of failures such as project overspending and time overruns.

Williams’ computer models are created at any point in the product’s life cycle:  As a feasibility study before the project begins to advise senior management about project strategies and risks; at mid-project reviews, or at project post-mortems when the project is completed.  Modelling such as this began as a tool for big defense projects, typically taking the role of a prototype project risk analysis tool.

This tool was given added value when it became important recently to pass risk from government to private industry.  Industry had to be sure that it was not taking on too much risk, while government had to be satisfied that it wasn’t being charged too much in terms of risk premium of having risk taken away from it.

There are several other arenas where computers can assist the project manager.  Thus far, the trend in software has been to provide specific tools for manipulating and communicating information on construction projects.  This computerisation of generating, storing and transmitting project information is commonly known as Information and Communication Technologies (ICTs).

Some of these applications are the responsibility of the resource manager, but all focus on Project Management Information Systems (PMIS).  The aim of PMIS is to ensure that accurate and current project information is available at the right time in the right format to the right person. 

Smith talks of other general areas where software packages are of great assistance to the project manager:

  -  Reporting Tools:  Reporting tools allow project managers to generate project reports that focus on relevant aspects of the project.

  -  Activity Modelling:  There is software now that offers network diagramming that automatically recalculate along the course of the critical path, as well as activity durations based upon changes to changes in resources.

  -  Task Categorisation:  Tasks are grouped usually in two forms, Work Breakdown Structures (WBS) that group activities under summary headings; and Organisation Breakdown Structures (OBS), which allow responsibility for activities to be assigned to departments, functions or workgroups.

   -  Resource Handling:  These software packages define resources such as materials, equipment and even human labour.  They allow the project manager to quantify the resource, detail its availability and associate with it a cost or rate.  Defined resources can then be assigned to activities, and the software determines resource usage per activity, and whether an activity is resource-constrained (a fancy way of saying you are trying to use more of a certain resource than is available).

 

Summary

This paper began from the following springboard:

Some business management theorists have argued that the level of technical complexity of the work determines how it is best managed.  To what extent does this argument taken from business management thinking apply to project management?

The finding here is that there is an unequivocal application of the above business management theory to project management.  In fact, many researchers cited in this study went so far as to suggest that ‘projects’ had blurred with business operations.  Projects, some argued, are the primary drivers of all organisations.  They are not merely separate components of an organisation’s business, projects are business.

Uniform acceptance of such a bold claim, of course, is not yet commonplace.  It can not be argued, however, that the attention of corporations around the world is riveted on their ability to successfully manage their projects.  And, this job becomes more difficult each year with the increase of technology and organisational size.

The administrative structures and tools of the project manager seem to change as often as the technical complexity in the work before them.  (Some may argue that this changes daily.)  From the abundance of new studies each year, researchers and practitioners seem keenly aware that project managers of 2000 must take new, highly disciplined, sophisticated approaches to the planning, implementation and measurement of their activities.

# # #

---