It was once a dark art. Those of us who practiced it were considered no less than fortune tellers, connected somehow to the supernatural, performing our strange rituals of calculations which once seemed no less outlandish than the science of alchemy seems now. When we were done we would create colourful displays of our results, showing that this project or that would now end 2 months earlier or 2 months later and there was no one present who could say otherwise.
Times have changed. Now project management methodology is taught as part of all management curriculums. Critical path calculations, barcharts and activity network diagrams are now as common as finance reports. Managing by project has become one of the hottest new trends in today’s management circles. It seems that everyone is doing it. There’s lots of incentive. The last 15 years has seen a period of rapid increases in efficiency in IT thanks in part to the drive for project management during the Y2K period. A more global economy and startling improvements in communications have allowed companies all over the world to compete for even the smallest amounts of business. No matter what industry you’re in, you’ve got to be able to deliver short product runs, be able to survive on the slimmest of profit margins, be as efficient as possible.
This trend towards management by project has allowed organizations of all sizes to compete on a more level playing field. Even a small organization can deliver an efficient project. But what does it take to manage an organization by project? Is it a new software choice?
The short answer is no. Projectizing a business starts with a structure change.
Most organizations have grown up as organizationally structured. If it was a family business to start with the most common structure is hierarchical. A family head at the top, vice-presidents below, department heads below that and so on. Even once the family is no longer involved, the basic structure will carry forward on its own momentum in a top-down structure. Fifty years ago, this was virtually the only management methodology.
Some organizations start in a more structured fashion or grow from hierarchical management environments to accommodate much larger companies. These groups may become more of a matrix organization. In a matrix, some managers are responsible for managing the departments, while others are responsible for getting work through the system.
A completely projectized organization would have no responsibility with a department. All responsibility would rest with the project managers.
Each of these methodologies has benefits and drawbacks, but they’re each worth considering for the advantages in efficiency they bring.
A hierarchical organization is typically able to change very quickly. Once the top tier of the company is convinced that change is required, others in the organization are informed and are expected to comply. The big disadvantage of course, is that any input from the lower levels of the organization which might have been useful is never considered. Also, if a change in management results in a less commanding presence than is expected, the entire organization might suffer (I’m sure I’m not the first person to wonder what Microsoft will be like once Bill retires).
In a matrix organization, there is a benefit of dividing responsibilities and, hopefully, getting more input from more management personnel. The department managers are typically responsible for the training, availability, hiring/firing etc. of their staff. They provide an expert-level service for work to be accomplished. The project managers use those services by requesting personnel for particular projects. They’re responsible for delivering the project. The downside to a matrix organization is the inherent conflict within the organization it creates. Perhaps in a perfect world this would be the most effective but in some companies, the pull of some managers to try to retain as much authority as possible makes the structure a breeding ground for upset. In a multi-project environment, some project managers will complain that their project isn’t getting a high enough priority for resources. Some department managers will complain that the project managers are “hoarding” their people. There is certainly more maintenance to the structure in a matrix environment.
In a project environment, there is the benefits that come from single-mindedness, concentrating on the project and its deliverables. The downside to this structure is the lack of belonging. Personnel wonder what will become of them once the project is completed and this sometimes leads to personnel ongoingly looking for work. Also, there is little allowance in this structure to take the lessons learned from one project and apply it to the next. This type of structure is most commonly found in mega-projects or in organizations which have been formed for the express purpose of completing a particular project.
Over the past few years, more and more companies have been leaning towards giving more authority to the project management aspect of their business. There is a desire from many CEOs to at least be able to track the company by project if not manage all personnel that way.
From a systems perspective this can be a huge challenge. An organization whose systems were built up over a period of years to collect, analyze and report data in one type of structure are often less capable of delivering the same types of results for another. Accounting systems, scheduling systems, payroll, even timesheet systems are structured to the needs seen by their developers at the time.
If you are in an organization which has determined that it is changing its basic management structure and you are responsible for some aspect of that change, you are likely going to have to deal with some systems issues.
Start by identifying what you are doing now and which data systems and reports are going to be altered. Sometimes this identification is very simple. Management might, for example, have made a new request that from now on, labour and materials costs will be reported project-by-project. Sometimes you’ll need to dig a little deeper.
Next start looking at how you will be able to collect that data by project rather than just by department. Don’t drop what’s working already! If you’re currently collecting timesheets from the department manager for instance, don’t assume automatically that you’ll now collect them by project manager and that the department manager will be dropped from the loop. What you’ll probably find is that there is some requirement from both sides to have access to that data.
When you start to implement your changes, go slow. Start with one aspect of the total structure. Wholesale changes all done in a single moment are almost always destructive. Make your small change and see how it affects the rest of the company. You may find that for some period of time, you’ve got to do double entry to take care of both aspects of the business. Grin and bear it. Keeping what’s working operational for awhile is great insurance against issues you may not have considered in the new structure.
You can continue to implement area by area following this kind of plan until you’ve reached a level which is comfortable for the entire organization. It’s entirely likely that this level is well before a fully projectized organization yet is much more projectized than you are already.
To help stabilize that structure, one of the more important things to do is to determine that new systems and new packages being considered and implemented will have the project-oriented functionality required for future moves in this direction. This is particularly important if, like many organizations, you are in the middle of replacing your core financial and management systems to become Y2K compliant.
The perfect balance for a particular organization is probably a balance between these structures and each organization must determine for itself which way to go. Changing software itself might make you projectize-able, but it’s going to require a change in management structure to make you projectized.