Tim Bryce asked:


“An elegant solution to the wrong problem solves nothing.”

- Bryce’s Law

INTRODUCTION

Commercial Project Management systems (PM) have been available since the early 1970’s. As PC’s proliferated in the workplace, so did PM software, which also brought an ease-of-use element to project management. A multitude of PM products are now available on the market, some expensive, and some very reasonably priced. However, to say all PM packages were created equally would be a gross exaggeration. Each has a specific niche they address in project management or target a specific industry.

As I described in my article, “Why Does Project Management Fail?”, one of the main reasons for failure is because there is a lack of consideration for the magnitude and complexities of project management and, consequently, there is a natural inclination to attack it in piece meal. As a result of the bulletin, I have been asked as to what criteria I would use to evaluate a PM package. Consequently, I have developed the following checklist for evaluating a PM package it its pristine form. I hope it will be of benefit to you.

GENERAL REQUIREMENTS:

The Project Management system should…

Support any type of project – large or small; not just those limited to a specific part of the business (e.g, IT pplications). As such, it should be flexible in application and accommodate any

and all methods of work effort (new development, maintenance, and modification/improvements).

Distinguish between Direct, Indirect, and Unavailable activities. For background information, see:

http://www.phmainstreet.com/mba/pride/pmmeth.htm#time

Promote the “Mini-Project Manager” concept. For background information, see:

http://www.phmainstreet.com/mba/pride/pmmeth.htm#minipm

Provide an integrated approach to support all activities of project management, not just some; this includes Planning, Estimating, Scheduling, Reporting, and Control.

Promote and enforce in-house project management standards; e.g., use of standard methodologies, labor rates, time reporting, detection of estimate/schedule overruns/underruns, etc.

Provide a universally applicable calendar and allow for the specification of a standard reporting cycle.



PLANNING SUPPORT:

The Project Management system should…

Support various Work Breakdown Structures (WBS) – not just a single methodology. This includes controllable levels of WBS (number of levels of detail). Also, provides a library facility for reusable methodologies that can be automatically loaded upon request. Ideally, the WBS can be tied to specific information resources (such as systems, programs, files, etc.) thereby enabling the ability to record and monitor time for a specific information resource.

Support internal project dependencies (work step-to-work step) and external dependencies (project-to-project).

Allow for multiple projects, multiple human resources (both internal employees and external contractors), and multiple assignments for a single human resource. (A “many-to-many” relationship between projects and human resources).

Provide a Skills Inventory to track skills and proficiencies.

Be able to manage project priorities and backlogs of user service requests (business objectives). A “priority modeling” tool is highly desirable to study the impact of change.



ESTIMATING SUPPORT:

The Project Management system should…

Provide for both Detail estimates (for a specific phase of a project) and Order-of-Magnitude (for the entire project). For background information, see:

http://www.phmainstreet.com/mba/pride/pm20.htm#types

Allow multiple versions of estimates (after all, estimates will inevitably need to be revised).

Provide a means to maintain estimating guidelines and generate tentative estimates accordingly.



SCHEDULING SUPPORT:

The Project Management system should…

Provide for automated calculations using “Effectiveness Rate.” For background information, see:

http://www.phmainstreet.com/mba/pride/pmmeth.htm#er

Allow multiple versions of schedules (project schedules, like estimates, will change over time).

Provide facilities to manage resource allocations. This includes plotting both estimated and actual project assignments, as well as monitoring “effectiveness rates.”

Be able to calculate critical paths of projects.



REPORTING SUPPORT:

The Project Management system should…

Provide facilities to record and verify time on project assignments.

Provide for the recording of “Estimate to Do” (the amount of time remaining on a given assignment). Note: This is different than “Percent Complete.” For background information, see:

http://www.phmainstreet.com/mba/pride/pm40.htm#etd

Maintain historical time data to be used in history reports and to update estimating guidelines.

Allow the recording of “out-of-pocket” project expenditures.

Provide a scratchpad facility to record project notes as well as formal reports (e.g. Project Proposals, Cost/Benefit Analysis, Project Audits, etc.).

Provide a standard facility to generate a variety of project reports (a “report writer” facility is ideal).



CONTROL SUPPORT:

The Project Management system should…

Post reported time to projects and to human resources reporting it. Also, post time to information resources to monitor activity. For example, the Order Processing system had 2,342 hours reported when it was created in 1985; 335 hours in 2000; and 246 hours in 2004.

Provide various summary reports to analyze projects and human resources, both by project and by department.

Provide the ability to bill end-users for project costs (Chargeback). This includes chargeback to multiple users at varying rates.



COMPUTER-RELATED CONSIDERATIONS:

The Project Management system should…

Be easy to install and test on the computer.

Be implemented as a cross-platform solution (operates the same on different computers) thus providing machine portability and independence from hardware manufacturers. It should also be easily accessed by all people participating in project management activities (conceivably the whole company) as an integrated approach.

Be easy to learn and use. It should be based on industry design standards (e.g., GUI design standards, on-line Help, use of operating system clipboard, etc.).

Performs reliably and productively in accordance with specifications.

Provide for multi-languages and multi-cultures, such as adapting to local customs for expressing dates, time (am-pm vs. military time), monetary values (Dollars, Pounds, Yen, etc.), and accommodating foreign languages (including the Asian Double Byte Character Set – DBCS).

Provide standard utilities for:

Monitoring and Administering the system.

Security – to both administer the system, and login to input data.

Import/Export data in various formats (Ideally an open interface should be provided).

File Management – to purge obsolete data, and backup files.

Be provided by a vendor with a reliable reputation for training, service and warranty.



I have described a pretty encompassing system with robust features. As such, a Cost/Benefit Analysis should be prepared to compare price versus the system’s value to the company.

This evaluation checklist should be used as a template and modified accordingly to suit in-house requirements. Good luck.

For additional information on “PRIDE” Project Management, see:

http://www.phmainstreet.com/mba/pride/pm.htm



Contents provided by Blog Kiem Tien

Tim Bryce asked:


“Having a Project Management system without a methodology is like attaching a speedometer to an orange crate; it measures nothing.”

- Bryce’s Law

The principles of Project Management have been with us for a long time. There has also been a number of Project Management software packages introduced over the years, beginning with mainframe based commercial packages introduced back in the early 1970’s. Some of it has been quite good, others are based on sheer quackery. Some people naively buy such packages in the hopes they will be some sort of panacea to cure all project woes; that projects will start to come in on time and on budget simply because a certain tool was purchased. Inevitably, they are puzzled when projects still go awry even with the latest software. I believe there are three reasons for this:

1. Companies are blinded by technology and fail to recognize the human dynamics involved with Project Management. Instead of working with people to successfully achieve their project assignments, they rely totally on numbers instead.

2. Companies fail to consider the total processes involved in Project Management and tend to attack it in piecemeal. For example, there are interdependencies between planning, estimating, scheduling, reporting, and control. Attacking only one of these problems will inevitably have an adverse affect on the others. In other words, companies fail to grasp the comprehensive nature of Project Management and tend to attack the problem of the moment, such as estimating or scheduling.

3. Companies believe Project Management is an end to itself; that by mastering the mechanics of Project Management, development projects will come in on time and within budget. They are easily shocked when this does not occur.

I refer to this last item as the “tail wagging the dog” phenomenon. True, the mechanics of Project Management are important, but too often people forget it represents nothing more than the dials and gauges to our business. To illustrate, a company using an assembly line process can effectively produce products without the aid of Project Management. The assembly line simply denotes the dependencies and sequencing of the work effort in order to produce a product. Project Management can then be applied to monitor activity and determine slowdowns and work stoppages or accelerations of production, all of which may require corrective action by management. However, trying to apply Project Management without the assembly line is an exercise in futility (it measures nothing). In other words, the assembly line represents the road map from which we will start and end our development efforts. Without the road map, Project Management is useless.

Ultimately, the assembly line represents the methodology for a project which defines Who is to perform What task, When, Where, Why and How (which we refer to as the 5W’s + H). Without a defined methodology, you simply cannot perform Project Management. Without the road map, you cannot plan; without a plan,you cannot estimate or schedule; without an estimate or schedule, you cannot determine if you are ahead or behind. Bottom-line: Everything starts with the road map.

Although companies may occasionally have a project using a unique methodology that will be executed no more than once, most companies have standard and reusable methodologies they use for different parts of the business. For example, a methodology for engineering a product such as an automobiles essentially the same for all such projects. The same is true for designing and constructing a building, performing customer service, managing finances, laying out marketing campaigns, or engineering enterprise-wide systems and software. Unknowingly to most, companies have a portfolio of reusable methodologies they regularly use on projects.

Methodologies consist of a work breakdown structure which expresses dependencies between steps in the project. Each methodology is normally defined using different levels of abstraction which breaks the project into smaller, more manageable pieces; such as phases, activities, and tasks. By doing so, the methodology defines the 5-W’s + H. Other characteristics include review points (for stop/go/revise decisions) and benchmarks used to substantiate completeness of a step within the methodology. Such benchmarks typically take the form of “deliverables” to quantify completeness before proceeding with the next step in the project. Finally, a methodology includes a beginning phase for planning,middle phases for execution, and a final phase for review or audit. As an aside, Industrial Engineers have been devising methodologies for many years (long before the advent of computers).

The current fascination with Project Management is healthy and should not be discouraged, but people should be reminded that it is only possible with an effective methodology; it is the Achilles’ heel to Project Management. Without it, you will inevitably drive in circles. This may all sound rather obvious, but as I have discovered in this field, the obvious isn’t always obvious.

If you would like to discuss this with me in more depth, please do not hesitate to send me an e-mail.



Contents provided by Blog Kiem Tien