Category: Articles

Home Articles ()

Creating an environment for project management

 

project_managementToo often in the project management software industry, we focus on functionality. We seemed caught up in the next feature, the cleverness of our programming and the frivolity of the next cute bell or whistle. Yet despite being the most mature of software categories (project management software was one of the first applications ever run on computers), over and over I see failed implementations.

What is common among the largest and most skill-laden firms in the country who have been unable to implement enterprise-wide project control systems? There are probably several answers to this but one of them for certain is the lack of an environment which supports a project control system. There is much to be said for better functionality and increased effectiveness of various algorithms and data storage techniques but if there is no listening from upper management for the proper implementation of these features and functions then there is no point to them.

So what can you as an IT executive do? According to Robert Graham and Randall Englund in their book “Creating an Environment for Successful Projects”, lots. Here are a few categories to consider:

  1. Develop senior management support
    There is perhaps nothing more important than this first category. If there is no understanding by senior management of what project management is, there is no hope of improving project performance. There are many techniques senior management can use to increase its support for the project environment. A project inventory for example, where every project in the organization is reviewed for status and performance. A mentoring program might also be effective. Having each senior manager adopt a project or a project manager.
  2. Creating an environment for project management
    Communication is everything and if the organization can adopt input from different parts of the organization then project then true project teams become possible. True project teams represent all departments involved in the project rather than the chinese wall method of throwing a part of the project over the departmental wall once finished. This method results in no one taking ownership of the project completing. A structure for interdepartmental communication is what is required to even start breaking up this kind of divisiveness.
  3. Develop a process for project selection
    Should you start every project that’s possible? Of course not. But do you actually have a formal process for selecting and prioritizing which projects are selected? This procedure is one that can make the difference between an organization’s survival or failure. Imagine choosing projects by virtue of circumstance then ending up in a situation where the projects you’ve got cannot be successfully completed by the skills available to your organization. Project selection can include whatever criteria you choose but consider some kind of cost/benefit analysis. You’ll want also to include some kind of risk assessment. One of your other criteria may be matching the project against the skills available to your organization. In our own firm, we recently no-bid the largest proposal we’d ever been presented with. I won’t bore you with the details but you’d recognize the company name if I mentioned it. The only problem with the proposal is that it was so large that if we started on it and failed, we’d put the entire company at risk of closing. The risk was just too high for the potential benefit.
  4. Develop upper managers’ abilities in managing project managers
    The number of organizations with this as a priority are few and far between but as soon as it’s mentioned, the usefulness of some kind of structured management of project managers is glaringly obvious. Are your project managers managed consistently? Are the criteria for evaluating the performance of the projects themselves even defined? The time for doing this is long before the project gets going. Once the organization is deep in the thick of a project and the heat is on, it becomes very difficult to change the rules on how project managers are to be managed. Start a program of training upper management on how to manage project managers. Better yet, include the project managers themselves in the training to get more ‘buy-in’ for the process.
  5. Establish a project manager’s development program
    If it hasn’t occurred to you by now, the importance of recognizing project management as a skill to be treasured can make all the difference to an organization’s success. As soon as that is recognized, a formal development program for project managers becomes an ‘of-course’. This needn’t be too extensive to start with. Any program with a track of any kind will at least set the stage for future refinements in the program. An element of this program that should be essential is budgeting time and money for these project managers to improve themselves. I can’t remember how many of our own users have had to take vacation time and pay for their own travel to attend user-conventions of the project control software their company depended on.
  6. Make project management a career position
    This kind of recognition pays back in two ways. First of all, you’ll attract good project managers to these positions. Secondly, your project managers will gradually become more and more effective if this is a career post with a future. The alternative is what too many firms do all the time. A project comes up and the employee with the least to do is thrown at the problem by upper management. This is, of course, because upper management does not realize the impact a trained project manager has on the outcome of a project.
  7. Develop a project learning organization
    My favourite book on this subject is by Peter Senge called “The Fifth Discipline”. I can’t possibly do it justice here but suffice it to say that none of what I’ve just described should be static. Your organization changes, flexes, adapts to the changing world around it. So should your practices and procedures! Don’t make the mistake of thinking that this is something to be written up in a procedures manual to be followed blindly until the end of time. Build into your procedures and practices, procedures for adapting and improving the structure.

Without an environment to support it, any project management system you try to implement has almost no chance of success. And remember, it’s never too late. Your projects may be underway and you may not be able to instantaneously alter your entire corporate culture but starting on support from senior management will help to deliver the rest of the structure over time.

Selling Project Management to Management or… Why is this so hard?

BusinessPeopleIt is a lament I hear almost every week. “How can I convince my management that we need to implement more project management?”

It’s not universal, of course, but the number of organizations where executive level support for the project control environment is either non-existent or openly negative is remarkable. Even more remarkable is that these same organizations often have executive level commitment or interest in better managed projects. What is it about implementing project control that makes executives so reluctant to take it on?

The issues break down into several categories:

By far the most significant category is a lack of understanding. Even with the advent of desktop project management systems such as Microsoft Project, the science of project management is complex and not grasped instantaneously. Part of the project is that project management and project management systems have become synonymous with project scheduling and project scheduling can be an involved subject. Network flow diagrams, Critical path scheduling, arcane terms such as “Total Float” or “Lag” make the subject even more daunting. Acronym such as “BCWS” don’t make it any easier for those people whose involvement in the actual workings of the project management process will be cursory at best. (By the way, BCWS stands for Budgeted Cost of Work Scheduled or, “the budget”).

Is the answer to this education? Special classes to train managers in how to calculate the Critical Path of a project? I think not. Why a manager should know all these terms is somewhat beyond me. In almost no cases will this make the person a better manager. Management’s input into the project management process is not to analyze the intricacies of a detailed project schedule.

To compound this problem, a second favourite category is the complaint of many project managers and schedulers is that on the subject of project management their own executives seem to have the attention span of a gnat! Decisions that, for a project scheduler involve detailed consideration of reams of data simply do not interest executives. In fact, the most common request by executives of their project managers is for single-page reports.

This problem can best be seen in public service. A cabinet-level politician or bureaucrat is so inundated with the day-to-day details of their department that they are often given no more than several minutes on a monthly basis in order to make momentous decisions on multi-million or multi-billion dollar projects. It is not that these people are not interested, just that this is the amount of time available for this type of decision at this level. I’ve seen several situations where this level of government official is given 3-5 minutes to give a go/no-go decision on continuing or cancelling a project worth well over $100million. To the project manager or scheduler, this lack of executive attention must be unbearably curt. Yet it is as common in the private sector as the public.

A solution? More time you say? I’m afraid not. Even doubling the amount of time spent at this level will still result in a ridiculously short amount of time spent analyzing the data. The problem is a difference in perspective.

Yet the demand in the executive suite for more effective management of projects is intense. Economic pressures increase the need for even more efficiency every day. For those executives or management teams struggling to understand what they must do in order to implement such systems, other differences in perspective continue to make selling project management to management difficult.

One of these differences in perspective is the notion that choosing the right software will solve the problem. The combined world-wide marketing efforts of the project management software hype-meisters leaves promises of effortless “enterprise-wide” project management on the pages of almost every major computer publication in existence. (Yes, I know, I’ve been guilty of this myself). With the current craze for ERP systems, and Office Suites which include project management functionality, this kind of promise is held out to executives as the holy grail of solutions to their woes.

Does this mean that software will make no difference? Of course not. But software is only one aspect of a solution and, in my experience, software implementations which occur in a vacuum devoid of management support, process changes, cultural consideration and a commitment to change inevitably result in failure. No, software alone does not solve this problem.

If you have been tasked to sell project management to your own executive or, if you are part of an executive and wondering why you should be interested, here are a few factors to consider:

  • · First and foremost, distinguish the perspective of the players involved. It is inappropriate to think that the interests of an executive responsible for the outcome of dozens or hundreds of projects and for the overall viability of an organization are identical to the interest of a project scheduler responsible for bringing several projects on time and on budget. This means that whatever presentations, reports, analyses, meetings and so on, must be tailored to who is involved. I’ve done hundreds of presentations on our own project control timesheet software and almost always have someone from the executive level of the firm in attendance. But I almost never have that person attend the entire presentation. We organize the agenda and schedule of the presentation so that the executives can attend the section most appropriate to them and leave if they wish (They almost always do) before starting the “nuts and bolts” of how the software works. Executive briefings almost never last more than an hour.
  • · Next, organize regular project management reports and presentations for management with the knowledge that there will be never be an understanding of the arcane terms and science of project scheduling and project cost control. Remove references to such items from your reports. If your project management software is incapable of doing things like renaming terms like “Late Start” to “Projected Finish”, start thinking about new software. In this case, less really is more. Keep your reports to a page or less and, if you must, keep a 2nd level detail in reserve to back up your analysis.
  • · Third, apply project management principles to your project of selling project management to management. Can I say this enough? The most infrequent users of project management are project managers on their own projects! How does this apply here? It doesn’t take much imagination. Define clear goals, get a project sponsor, set a timetable…you know the rest.
  • · Don’t be enthralled by the notion that the purchase of any one piece of software will instantly and completely solve all of your project management problems. The implementation of software is sometimes a perfect time to effect a culture change. Sneaking in a new paradigm of behaviour on the back of a project control system is a favourite technique of mine.

You’ve got to look at the whole project control process whenever you’re interested in improving the effectiveness of project management. If you’re interested in selling project management to your own management, start with identifying management’s role in the process. Where do they fit, what is their contribution and what impact will that contribution make to the enterprise? A request for input when that input will clearly make a direct difference to the outcome of something is irresistible to almost everyone.

Managing IT Projects in a Sea of Change

72762531If the world would just slow down for a minute, maybe we could get something done. The biggest problem with IT projects is that nothing in the project is ever stable. In other industries, there are elements which are stable enough that they can be counted on for the duration of the project. Carpentry skills and carpentry tools have had very few changes in years. Yet, in a major IT project, almost every significant aspect of the project is likely to change during the execution of the project.

The design that never ends
Over the 12-24 months that a major IT project is likely to take, many elements are likely to change. The design of the target application itself is almost always impossible to close.

In a commercial application, choosing the target functionality is often driven by a combination of factors including feedback from current clients, beta test users and focus groups. The target platforms may be different both from a hardware and software perspective. Imagine how many applications in the last two years have had major platform target changes as marketing directors run into the development department and declare that unless it’s in-the-cloud-enabled there’s no point in writing it.

In an internal system, the demands of the client change as they watch the world change around them. Thanks to the Internet, never before in the history of this industry have so many people had so much access to so much information about software. While the IT department is trying to pin down the exact requirements, users at virtually any level of the organization can find similar commercial applications or articles about such applications on their Web browser.

Hardware changes
Only a few years ago it seemed quite reasonable to amortize PC hardware over a 3 year period. Accounting firms still have formulas for amortizing PCs over a five year period (I’m not kidding, I ran into this only last week). As everyone knows, computer hardware is obsolete almost before it’s delivered. Over an 18 month period, the hardware that the project started on is invariably not the hardware it will be installed on. Since most users are changing their hardware to be larger, faster and better, this is not often a critical concern. Where it can become a problem is where hardware is upgraded with the programmers first and the software then only works with their hardware.

Operating System Changes
The switch over from Client Windows applications to browser based was a traumatic experience for most developers which not everyone has recovered from yet. Whenever a new version of an operating system is released and users across the enterprise begin to upgrade, programmers suddenly find themselves scrambling for compatibility. Any operating/system-provided layer becomes an issue. This includes data connectivity such display based modules.

Programming Platform Changes
While everything else is being changed, the language itself that the development is being done in is changing also. We suffered a 60 day delay in a new version of one of our projects earlier this year when our development environment got a new upgrade which we deemed essential to fixing some known problems but that required a re-write of our installation scripts and a whole new testing cycle. This kind of thing can happen all the time and it needs to ba managed.

Database upgrades
With so many IT projects now counting on commercially supplied databases, any upgrade to these products can have a dramatic effect. Do the drivers exist from all other parts of the project in order to connect properly to this database. Should you be reverse compatible with earlier versions? Should you not upgrade and risk not getting the new features and, worse, the fixes that are surely in this version?

Third party products
If your environment depends on any third party products, then the problem is compounded geometrically for each third party product that’s included.

Remember, everything needs to come together at one time. The operating system needs to be compatible with the hardware (noticed the PCs that have “We’re not quite ready for that version of Windows”  notices?). The database needs to have the features requied to support the project and needs to have drivers which can be accessed by the hardware, operation system, programming environment and third part tools. The third party tools need to be compatible with the hardware, operating system, programming environment and database. The programming tools need to have the drivers for all of the other components working simultaneously. Finally, the design needs to be something that can be delivered by the tools selected in the first place.

It’s a wonder that the combination ever turns out but when one element changes, all the others might have to as well.

If you’re managing a major IT project keeping the ship moving in this sea of potential mines is no trivial task. Still, there are some things you can do and some methods of operating which can mitigate the risk.

For hardware changes the biggest problem comes when the developers have their hardware upgraded first and then the software is written to fit inside their premium sized boxes. When the application is deployed smaller terminals suddenly need to be upgraded in order to function with the new software. One of the ways to mitigate this risk is through the QA process early on in development. Let the programmers write and compile software on the fastest machine in the building, but make them test it on the slowest. There’s nothing like making a programmer stare at a slow screen to give them incentive to speed things up.

For operating system changes, the best recommendation is “go slow”. Each change, even when it seems minor needs to be tested in the field. And every change can have a cascading effect.  In our office for example we found that testing the last release of Windows wouldn’t support some of our older but still perfectly functioning monitors.  Rather than upgrade these machines, we’ve left them on earlier versions of Windows until the monitors can be upgraded or the hardware retired. The cost of upgrading hardware in order to make the latest operating system work can be prohibitive so it’s not to be taken trivially. Make sure when the project starts just where the client operating systems can reasonably be expected to be over the coming year and write to the lowest common denominator.

For a programming platform the problems can be more severe. If fixes inside the programming platform mean that an upgrade is required, then run a test development platform to ensure your existing code will port to the new version. Earlier this year we were obliged to move to an upgraded programming environment only to find that some of our existing code had run afoul of an unreported bug in the new version. Since the new version was not 100% backward compatible for this particular feature, we were obliged to spend several days writing work-arounds for the code. If you’re sure you can upgrade the development environment successfully, assess the effort required, if any, to upgrade essential components to legacy users in the field. Your other option is to continue with the older version for some time with work-arounds where required.

Database upgrades are something to also take on with some caution. Database providers are also regularly upgrading existing versions and releasing new ones.  One experience we had recently had us move to an upgraded version of a database product which fixed several minor problems and threw a much more terrible one at us which we had to struggle with. If possible, patches, upgrades and, in particular, new versions should be run first on a mirror testing site to ensure they won’t cause any problems. In particular the availability of new drivers for all the other components is often not assured. Ideally, choose a database platform at the beginning of the project and stick with it until the first version is released, make an upgrade to the database coincide with a new version of the application.

For third party products, the rule is use the fewest sources possible. If third party products are essential to the application then access to the source code is likely something that should be considered. The worst case scenario is that a small third-party supplier goes out of business just before the application can be released leaving you with outstanding technical problems, no upgrade path and no support.

Finally the most ephemeral aspect of any IT project, the design. I’d love to tell you to firm up the design before you start, carve it in stone and bring it like Moses down from the mountain to be seen by all but it’s just not realistic. With a world that changes as fast as ours does, the chances that even the best written design specs (and most of them aren’t) could survive the 18 months or so the project will last are almost nil. The best way we’ve found to mitigate this risk is to modularize the design.  ITIL processes have come to adopt this kind of thinking. IT projects are almost always design/build projects anyway. (This means the building will be going on while designing is still occurring). If you can modularize the coding of the system by function and then use basic good programming practices for standards like object classes (dialog boxes, field types etc) then tossing functionality in or out of the design becomes much more palatable. Around here we often say “it’s better to look integrated than be integrated” and if only for the design problem alone this is very true.

Regardless of whether your project is a commercial or internal application, working in a sea of change makes the project risky. Keep yourself open to change when it occurs but if you’re to be successful, start working on the first day of the project on contingency plans to mitigate the risk.

 

Projectizing your business

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

Integrate or Interface?

integrate“Sometimes it’s better to look integrated than be integrated.” It’s a saying that goes back a few years now and I can’t even remember who coined the phrase first. I do think about the concept from time to time though. It seems most appropriate in meetings such as the one I had last week where a senior IT executive asked me to comment on a 15 page data flow diagram showing how a legacy timekeeping system would be integrated with the system we had recently supplied.

Fields were mapped representing data in both systems, stored procedures were referred to but not defined. The understanding of how data was to move back and forth between the systems was sketchy at best. What was perhaps most unclear was what benefits were expected to be realized by the organization through this extensive amount of work.

This is not an isolated case. In our work implementing project control environments we’ve had plenty of opportunity to look at extensive ERP implementations where months of effort are allocated for “interfacing” which typically refers to full integration of data between multiple usually non-compatible systems.

What is it that makes this kind of exercise so compelling? Well, it makes for great marketing hype. If you’re in the business of selling man hours for implementing enterprise systems, then this scenario is made in heaven for you. Pretty PowerPoint slides showing lines of data moving between all these systems and suggesting that management will be able to get completely integrated data are enthralling. Not long ago I watched a demonstration showing a financial report on screen which, with a click of a button, dissolved into a pie chart. From there to a histogram and a click on the histogram and the graph broke into a spreadsheet showing multiple suppliers. One more click and this list became another graph and from there down to an individual invoice. To say that this demonstration got the attention of the potential client would be an understatement. These executives were virtually salivating, imagining an ultimate level of control of their own organization’s data.

The truth is not always so easy. In practice, data must often be approved and batched together before analysis. There usually needs to be a defined flow of data from one place to the next and, if as is almost always the case, this data will come from multiple systems which may or may not (probably not) have been designed to integrate their data together.

As I’ve often said in these pages, the most effective analysis of such decisions is one where the Return on Investment is measured. A demonstration which seems delightful is not enough reason to start integrating systems which must be done at an architectural level.

In the 15-page data flow diagram I recently had to confront, data moved from one system to the next, other elements moved back to the first and more elements again moved back to the second. It was difficult even to follow the logic. This might have been worthwhile if there had been some measurable benefit but if there were big gains in efficiency to be found, I certainly couldn’t recognize them. The legacy system was, of course still there but the initial impetus for integrating the two systems seems to have been for the purpose of producing a single report which would show total hours across departments.

Even if such a report had been required it would have taken the tiniest fraction of effort to import the data from the legacy system into the new system in order to produce the report. “Ahh, but that would require intervention every single month,” I was told. “Good point,” is my reply. “However, the 15 minutes it would have taken every month is by far less than the 4 weeks spent writing the integrated design and code and the countless hours spent trying to keep the systems in synch!

Interfaces have another hidden benefit as well. Having to intervene to create the interface is a perfect point of control to manage the data flow. If you’ve got a checklist item in your procedures which says “import the timesheet actuals” then having to physically click an icon or select a menu option and to ensure that it runs is a great place to make sure that item is complete and that all data has move from the source system to the transaction file and from the transaction file to the receiving system as required.

Many finance departments have this in their periscope already. Many systems promote their “open architecture” database as the holy grail of systems integration. There’s no doubt that an open architecture provides more options than a closed architecture but the picture painted is often too close for comfort for finance people. Finance systems are, after all, tough to get stable and once stable, there is a tremendous reluctance to touch them even for upgrades. Every time I’ve suggested that we’d be prepared to intimately integrate the data from a project control system into the accounting system directly, the finance staff have stared at me in horror. No, they say, it would be far preferable to deliver a “transaction file” to finance for importing when they’re darned well good and ready. The idea that an “external” system (for Finance, this mostly means anything outside the GL, AR, AP, PR package) would change cost values in the main accounting system without human intervention is abhorrent to most finance personnel.

While this is true for the systems we’ve been implementing, in many cases it will be equally appropriate for other internal systems to follow the same logic. When an interface can deliver the result at a fraction of the investment of time and effort, then you’ve got to take a careful look at what it’s providing. Far better to interface systems in an organized fashion than to spend the next 6 months trying to determine why the “integrated” system isn’t.

Biting off more than you can chew

BusinessPeopleIt’s happened three separate times this month. In hindsight it’s obvious but it amazes me that large organizations whose staff should really know better continue to bite off larger enterprise-wide implementations than they’re capable of delivering. The problem is, to be sure, insidious. After all with “enterprise-ready” software hype available in every publication, you might be lulled into thinking that just choosing the right software means that everyone in your organization will instantly become an integrated machine with all parts harmoniously moving in the same direction. The problem is, implementing enterprise-wide software of any category is much, much more than the purchase of the package itself.

I’m sure no implementation starts out this way but, for the three companies who I spoke to about it this month, they certainly ended there. I’ll not name these firms but, you’d recognize each of them instantly. One, an insurance company, the second a financial organization and the third a telecommunications company. In each, the issues were similar yet distinct. Each of these firms has an interest in making themselves more efficient by implementing project-oriented software. Sounds simple enough but even in this sentence the mischief starts. “Has an interest”. Well, firms don’t really have an interest, people do and if a firm is large enough, it is represented by many, many, many people. Part of the problem with implementing any kind of solution that will affect everyone in the enterprise is finding out first, how the enterprise will determine its wants and needs. Should it use the democratic method? Everyone puts in a vote and the solution with the highest number wins? Should it manage by consensus? Dissenting voices are managed one by one until there is some kind of movement in a single direction? Should the decision be made hierarchically? The executive at the top of the food chain decides and everyone else follows the lead? The answer to all of these may be yes… or no. Each firm’s management, for each situation must determine what degree of seriousness to allocate to an enterprise-wide plan.

I/S managers who might have spent years cajoling, teasing, arguing, forcing, enrolling and trading with their fellow managers in an attempt to generate enough consensus to move an enterprise-wide solution forward are often given the full authority of management to implement such solutions. In the past year I’ve seen Boards of Directors actually make operational decisions on software and on implementation schedules, something that in the 5 years previous would have been unheard of. With that kind of authority, anything can be implemented.

Yet, not every solution carries that much weight behind it. How do other enterprise-wide solutions get chosen and implemented?

In the case of the insurance firm, a committee has been struck with a mandate from the highest levels of management. Yet the mandate wasn’t clear in how it should be accomplished. In this firm, a couple of mainframe-based applications run high-level project tracking for the finance group. The goal is to eliminate these cumbersome systems and replace them with more modern reporting systems. The first idea was to look for a commercial system which closely matched the existing functionality. Surprise, surprise, no one has exactly the functionality required in a single system. While the requirement specification was being created to even evaluate systems however, the project increased in scope. Why look for obsolete functionality, the argument went, when we could create a state-of-the-art enterprise-wide project control environment? It sounded wonderful and the team was inspired. Now the search was on for multi-project, enterprise-wide systems which could integrate the work of thousands of employees and hundreds of supervisors, project schedulers and managers.

It sounds wonderful, but there was a small fly in the ointment. The majority of end-users are already using desktop project scheduling software from a funny little company based in Redmond, WA. While very popular among end users, this software was deemed insufficient for managing the centralized, cross-enterprise needs of the firm. “Did the committee,” I asked, “have the mandate to replace this software across the board?” “Well… no.” was the answer. But, some committee members thought it was such a good idea that they were determined to lobby for the notion. It sounded like fighting the good fight but without the backing of the highest levels of management, this committee was destined for failure. Trying to replace the desktop product would ultimately be so contentious, raise so many issues and concerns, step on so many toes that the committee would be handcuffed in implementing anything.

At the telecommunications firm, the news was similar. Here, one division has successfully implemented a project management system across their entire group and have come to the conclusion that if only the other 30,000 employees of this firm would see things they way the 1,000 of them do, everyone’s life would be easier. Nice plan, tough execution. This firm, like most high-tech telecommunications firms these days is enjoying explosive growth and changing directions and goals faster than can be imagined. The only way these firms survive is to compartmentalize their operations, leaving each group somewhat autonomous with significant discretionary power. The individual groups agree on virtually nothing. It is, in some ways a problem but it comes with the territory. Implementing an enterprise system that could only be used successfully if everyone agreed on how it would be used, how data would be analyzed, what quality of data would be included and last, but not least that all … every bit of data would be entered into this particular system is going to be very difficult. The original idea was valiant but in this case, even if the CEO himself thinks it’s a good idea, deploying such a system is going to be tremendously difficult if it’s even possible. This presumes of course that the product(s) that are selected and that they attempt to implement can even carry the load across such a large number of users with so many diverse interests.

In the case of the financial company, reason has somehow prevailed. Here, the original notions of an enterprise-wide planning system have been toned down. Technicolor plans of real-time resource management with instant management oversight have resolved to a more modest first phase approach. This firm has elected to implement only one of a wide range of elements that may one day make up the final solution. In this case, the first element is an activity-based timekeeping system which will, of course, touch every employee in the firm, yet is already somewhat culturally accepted. This first phase, will deliver some of the results management has been looking for with an ability to closely approximate some others without having to deploy tools or collect data from every user.

The lessons seem to stay the same. If you are contemplating implementing an enterprise-wide solution consider some of the following elements:

Ø Do you have the authority to do so? Has someone high enough up in management; someone with the authority to impose this solution if need be, requested that this solution be selected and implemented and; do they understand what kind of commitment will be required of them if the plan moves forward?

Ø Is there a need? If end-users are already satisfied with whatever solution they may be using at the moment, how will you convince them to switch? What benefits will this solution provide to each level of the enterprise?

Ø Finally, consider a phased-in approach. After all, if it’s all or nothing, then you’ll need to wait until the entire system is selected, installed, configured, loaded with existing data, tested, people trained etc until the first byte of useful return will come out. This may take months years or… forever. A phased-in approach lets you get small victories with benefits along the way. It’s true that the final dream system may stay forever outside your grasp this way but… was it ever really within your reach anyway?

Critical Path… Not so critical?

pert_exampleA couple of years ago there was a brief flurry of product announcements of new software systems which would seamlessly (don’t you love that word?) marry the functionality of traditional project management systems with every employee’s To-Do list. The products (including one from Microsoft itself) were short lived and we’ve not seen their like since. Recently however, I’ve noticed a number of requests for such functionality returning and thought it might be worthwhile to take a moment to give the idea of such systems a reality check.

First of all, let’s get a basic definition sorted out. When people refer to “project management systems” they are typically referring to project scheduling systems such as Microsoft Project, Primavera etc. It’s true that these products are in the project management category but it’s a little unfair to consider the functionality they deliver to be a complete answer to all project management issues. After all, there are many other elements to project management than just the schedule. Contract management for example is a huge component of any project management environment as is team management, communications, client meetings and so on.

Still, the first software ever delivered for project managers was scheduling software and so long as we keep straight what it can and can’t do, it’s not too harmful to call it project management software.

Virtually all of the scheduling software on the market today is based on a type of calculation designed about 50 years ago and honed over the years by various project management practitioners. It’s called the Critical Path Method or CPM for short. I won’t bore you with the textbook details but suffice it to say that the purpose of CPM is to determine the shortest period possible for the project to be completed in. There are also a range of other algorithms which could be considered but this is the predominant calculation used for all major scheduling tools on the market today.

Combined with the Critical Path calculation is usually some kind of resource leveling calculation which identifies where you may be short of resources or what the schedule impact would be of not hiring additional resources.

Ok, so what does this have to do with the price of eggs? Only this: These algorithms were designed for mega projects years ago when the notion of a project was hundreds or more likely thousands of workers in a few identifiable categories working on thousands of tasks over years of a project. There are even textbooks of the era that suggest that the minimum duration of a task should be measured in weeks or months rather than days or hours.

Why is this a problem? Two reasons: First, the world has changed and is changing faster and faster as time goes on. Projects are typically much shorter. The era of the mega project if not gone is in hiding. Project management is no longer the purvue of only the large defense/aerospace or huge construction organization. Now everyone would like to do it. Not only that, but the amount of disposable time available to everyone is much less than in times gone by. Managing your to-do list in your Day-timer is now mandatory to get through your day.

Secondly, it pegs existing project management software into one category: Analysis. No matter which way you turn, no matter how user friendly the next version of Microsoft Project or any other vendor, in the end scheduling software is designed to perform and display the results of a calculation. This is fine if you accept the software for what it is; take your results and then go off to make your own decisions. This only becomes a problem when we take the results of a complicated analysis and try to marry it with an action-item system.

You may be seeing the problem by now. When we take the results from a scheduling system and try to use them to determine tomorrow’s to-do list, we skip the “eyeball” analysis which comes from every supervisor who, in his or her head, analyses a thousand minute variables before tasking employees with a particular piece of work.

For example, it may make perfect sense to a scheduling system that in a given week Mary should do the analysis on project 1, then move to project 2 and work on the documentation there, then move back to project 1 and finish off some testing. But a supervisor may elect to have Mary finish project 1 in its entirety because the dynamics of pulling her off the project team prematurely may upset everyone on the team. This kind of human element is impossible to design into an algorithm but may be perfectly obvious to everyone involved.

If you’re reading this, thinking you’ve just invented the human factor algorithm and if I just knew about it, everything would be fine, hold that thought. A much more significant factor is something I call ‘level of resolution’. A scheduling system has a perspective of weeks or months or even years in creating the schedule. Can you imagine filling in your agenda for a task to do 2 years from now? It would seem nonsensical, yet that is essentially what a scheduling system does when it does resource scheduling.

The reason that no one puts it into your agenda is that the likelihood of that task actually happening on that day 2 years from now is extremely low. Even when we take a one week perspective your agenda won’t hold up. Don’t think so? Let’s take a show of hands. Put up your hand if you worked on something today that wasn’t on your to-do list when you started today. Look around. See a lot of hands in the air? Me too.

It’s an insidious issue though because the data sure looks the same between both types of systems. We can match due dates, descriptions, resource requirements, almost everything together… The problem is level-of-resolution. The data just doesn’t belong together.

Still, waiting for the magic solution? Sorry, this time there’s not one to be had. I believe that we’ll see a new paradigm of project management systems in the next couple of years which take a view other than just algorithmic or at the very least, move on beyond the Critical Path Methodology calculation to something which is designed for today’s kind of projects. Perhaps then we’ll see systems which can move into the level of daily to-do list from the level of project without incident.

Until then there’s still a lesson to be learned here which is universal. If you are looking to integrate systems together, you’ve got to do more than map the common fields in the separate databases. You’ve got to look at the data in its own context and see if it fits.

– – –

Third Party tools part of ERP Solution

7252413There’s something that I’ve been wondering about for awhile now. We all know how incredibly the ERP market has expanded in recent years. There are a number of ERP competitors who have seen themselves grow a hundredfold since their lean years.

The promise of the ERP solution has always been enticing. After all “Enterprise Resource Planning” holds even in its title the promise of something all encompassing. Many ERP vendors promised to deliver all key corporate computing functionality from a single source. If you look back two to three years at ERP marketing campaigns, you’ll find a leaning toward offering everything from the same vendor. For some organizations and some management people, it was the holy grail of computing environments.

If you’ve worked on an ERP solution implementation team, you already know the drive toward keeping the entire solution inside one box as long as is possible.

Ok. It sounds wonderful. So what have I been wondering about? I’ve been thinking, that if the promise of these ERP vendors was to offer “everything” themselves, why have so many ERP vendors created so many alliance partners?

Stop by any of the majors; SAP, BaaN, PeopleSoft, JD Edwards and Oracle and you’ll find a plethora of add-on products, third party solutions, enhanced functionality and more. Some of the solutions you’ll see are already listed in the functionality of the ERP product.

There’s no mystery why these products exist. With the ERP market so dynamic, many firms (my own included) have placed a high priority on creating ERP add-ons. The mystery is why the ERP vendors agreed to assist these firms with marketing by putting them onto websites and listing them in catalogs.

When you think about it for a moment though, the source of the phenomena is obvious. Actually implementing a complete replacement of a corporate computing environment is a stunningly complex project. No matter how elaborate the project schedule, how extensive the planning and preparation, there is simply no way to turn on such an extensive system on a given day and from then on simply operate on the new system. Even in the simplest of implementations, the system must be installed in phases.

With many ERP systems, it is the core financials which are implemented first. This includes the General Ledger, the Accounts Receivable and Accounts Payable. Sometimes there are other essential ledgers which must be established at the same time. The secondary functions such as inventory, manufacturing, project control and other ancillary systems are scheduled for once the essential financials are stable. Tertiary functions are held off until all else is complete.

I’d be fascinated to see statistics on how many organizations who have purchased complete solutions have only completed the core first phase and have now elected to postpone or even cancel subsequent phases.

It makes some sense to figure that this must occur in some firms. The source of many firms wanting to switch to a completely new financial system is routed in the Y2K problem. With massive costs of upgrading systems that had evolved over time, the incentive to switch to something already written is huge. Add to that the “gravy”; the complete solution that was held out by such vendors in taking over everything else and you’ve got a good case for selling some software. The problem has never been in selling the solution, it is in implementing it.

Such systems can only be sold in a centralized manner. After all, they cover so much of the company that only highly placed executives will have the authority to purchase and start implementation of such a system.

Deployment of the core functionality is restricted to the key financial people who were probably involved with the initial evaluation of the system. Once the initial implementation is complete, however, the deployment of the balance becomes much, much more complicated.

Each additional module will have targeted a particular area of functionality. Some of these areas will be restricted to individual departments, others will be broad band. In both cases, many of the people involved with the deployment of these modules will not have been involved in the initial evaluation. Implementing a solution for such a module will require additional effort. It’s like attacking a village; house to house. Even with unlimited resources (and who has those?), all these secondary and tertiary systems cannot be implemented simultaneously. For one thing, some modules depend on the data from others. Much more importantly though, even trying to implement too fast is just too much culture shock for many firms.

It’s no wonder that the further you go from the centerpoint of the system purchase decision, the more likely it is that some departments will be looking for at worst interim solutions and, possibly permanent solutions for their particular function.

Not too surprisingly, as the ERP vendors themselves have had a lot of opportunity to see their original product implemented over time, some of them have found that there are ways of doing business that simply haven’t been allowed for in their system.

Sometimes third party solutions can be found which enhance existing functionality from the original ERP system. Sometimes, a third party tool simply does something more effectively than the internal tool.

Purists may take issue with inviting the consideration of third party tools but I think it’s inevitable. It’s now a given that a phased-in approach to implementation of such a system is more effective than trying to do it in one big bang. If the solution is being implemented module-by-module anyway, why not look for the “best of breed” for each of these modules as it comes time to implement them.

I have no doubt that this ERP “after-market” is not only growing but that it will continue to grow well after the millennium clock has ticked over. ERP vendors and the suppliers of 3rd party tools which are linked to ERP systems have tremendous potential for growth as these “core-financial” installations move into their second and third phases.

– – –

Deploying Multi-National Applications

7279155Enterprise-wide software is complicated enough but when the application must be distributed across multiple countries, there are elements of complexity that must be considered long in advance of the start of implementation. When data from a system that spans multiple countries spans multiple countries, cultures, time zones and environments must come together to form a coherent picture for management, some additional thinking must be done in advance.

At our firm we’ve done enterprise wide project control systems for years and on many occasions with multi-national firms but it was not until this year that we had to deal our first multi-national implementation of one of our systems.

When a data-oriented system such as an ERP environment or, as was our case, an all-employee project oriented timekeeping system must be deployed in such an environment, there are several areas to consider:

Language
Is the software you’re installing even available in a local language? Is this important? If the system is available in a local language, is it the identical version that is available in English? (Often not). Will the data be saved in exactly the same way when it’s stored in a foreign language version (for example, 2-byte characters for some middle-east and far-east languages)? While we’re speaking of languages, how will you handle training, consulting, implementation assistance and technical support in the local language?

Communications
How will the systems communicate with each other? Is there a data pipeline already established and is it fast enough to handle the anticipated traffic. How reliable is the connection. If it’s not, will your system allow for data to be pooled then transmitted in a batch? In some countries, PCs and other computers are readily available but fast telephone data connections are not.

Multi-platform
The larger and more diverse the implementation, the more likely that you’ll find different hardware platforms, operating system platforms, database selections, network environments and so on. Is the system you’re looking at ready to deal with this diversity or have you budgeted the costs of switching some areas into a common operating environment? If so, remember such an action affects everything else already established on that environment.

 

Configuration management (upgrades)
You may find it a challenge to keep up with software upgrades, patches, fixes and so on but when you’re dealing with such items at great distances, the challenges become much more difficult. Have you established a plan for upgrading the system and for maintaining it?

Real-time data and time-zone issues
This one is insidious and many, many people don’t think about it but if you are planning to move data to a central location, it often must be closed or grouped at some specified time or date. For example, month-end closings. If you have not allowed for multiple time-zones, this can cause tremendous upset. If the head-office is in Toronto and some of your users are in Australia, you can be dealing with a 12 hour time difference.

 

O/S and local version issues
It’s not enough to tackle the local software versions, what about the local operating system and systems which must be integrated. The other day, I walked through our technical support office only to find a Microsoft Project 98 CD on someone’s desk. That in itself isn’t too unusual. Our timesheet system links to Project98. What caught my eye was that it was the Swedish version and no one in our office speaks Swedish. Sure enough, it turned out that we had to make adjustments in our product so that the data could be linked properly to the Swedish version (and other European versions) of Project98 as the system was not properly recognized. We’ve had to make similar adjustments for Regional Settings in Windows and for different language data.

This may seem like an overwhelming challenge but there are numerous methods of handling it. Here are a few you can think about:

Make a Project Plan
Can I say this enough? Make a plan. If you don’t, this kind of detail will come up to bite your behind and the consequences to your implementation schedule can be monstrous. Include in your plan a list of potential risks you’ve identified already and canvas your international colleagues for risks they may be able to think of.

Identify a Local Champion
Put someone on your implementation team from each major region and put them on the team from the beginning. This will keep these countries in the loop and give you a better chance of identifying issues before they come up.

Look at alternative platforms
Server based code for example, allows you to beat the configuration management issues by centralizing the application and distributing working through the Web. Sounds great but there are technical issues here too not the least of which is security. Make sure the technology you choose gives you the capacity to handle the workload.

Think about being less integrated
I know it’s an enthralling prospect and the salespeople had the CEO loving it during the product demonstration but make sure that integrating all these countries will have a bigger payoff than the cost in time, money and effort. “Sometimes it’s better to look integrated than be integrated,” I say and it often holds true for this kind of thing. You can still be compliant and use data that can be brought together in batches without having to have all the data talking to each other all the time. Deciding to establish regional data centers where data is pooled as though it was a separate organization can solve multiple networking and data movement issues.

Make sure there’s local support
No matter how great it sounds, there has to be local support for your application of some kind If it isn’t there, budget for creating it yourself because supporting enterprise applications from a different time zone is very difficult.

Finally, make sure your schedule allows time and budget for prototyping, testing, travel and lots of “miscellaneous”. Build some extra slack into this element of the schedule. You can make this even better by avoiding promising particular structures prior to starting. If your design has promised management a “Real-Time true client/server link with transactions updated second-by-second”, then be ready to wipe some egg from your face. Some countries can at best muster a 1,200 baud data connection out of the country. While I remember getting my first “high-speed” 1,200 baud modem, it won’t be fast enough any more to take care of moving corporate data in real time for a client/server system.

If you take some time doing preparation in your project plan and creating some contingencies to the risks you’re facing, you’ve got a much better chance at bringing your organization closer together and helping to make the world a smaller place.

Managing time or time management?

100110In our office we spend a lot of time talking to large organizations about how to implement labour control systems. It’s not coincidence, after all, we publish timesheet software but what’s surprising is the wide range of expectations of people who have been brought together to choose and implement the new system.

The first element of complexity that drives many of the issues is that a timekeeping system is one of the few if not the only centralized system which will be so wide distributed. Typically a timesheet system needs to be used by every single employee and put onto every single desktop. There is no other database-oriented application which will have to work together yet be used by so many. The larger the organization, the tougher the problem.

With more and more organizations becoming projectized, a desire to get a handle on actual labour spent is becoming a higher and higher priority in many companies. This often brings together a committee mandated to find (if possible), re-write (if absolutely necessary) a timekeeping system that will allow management a greater degree of control over timesheet data. The collection of people in such a committee often makes for some surprises. After all, collecting some timesheets should be a fairly low-priority function right? ‘Fraid not. First of all, while filling in a timecard, or timesheet at the end of each week is often a low priority for most employees, the need for that data can often be one of the highest priorities for the organization. If, for example, the payroll is keyed off the timecards, then not getting that data collected means no paycheque on Monday, something that is a high priority for most of us. Second, because so much of the company (if not all) has to use the system, it is very common to find representatives from all aspects of the organization. For what is sometimes the first time, Marketing finds itself in a meeting with Engineering, Administration, Production and Management. For these two reasons, it is not uncommon to find the committee also has some highly placed friends. It may actually have the Chief Financial Officer or Chief Information Officer actually on the committee itself.

So with all this highly placed interest, you’d figure that most organizations would at least have a clear idea of what it is they need. Well, that’s unfortunately not often the case.

Part of the problem stems from a general lack of consensus over what function a timekeeping or time management system should perform. For some users, an agenda system similar to Microsoft’s Outlook seems like just the ticket. This “to-do” list has, after all, a place to record how much time a task took. Surely access to such a system would satisfy the needs of management? Such systems fit the role of time-management systems from an end-user perspective just as a Day-Timer or other hard-copy agenda would.

Another perspective often stems from the Human Resources department. Here, the management of “exception-days” such as vacation or holidays or sick-leave make interest in a management-by-exception system that is usually referred to as “Time and Attendance”. Time and attendance systems look to provide minimal information as they only look at anything that isn’t the expected work-week. In a salary-only environment, this is also enough to manage the payroll and a time-and-attendance system will often be used for this as well.

“Punch-clock” time systems add to the general confusion as the security department pipes up to say that they mag-card system that gives staff access to the front door is already keeping a running data stream of who’s in and who’s out. Surely the data from this system could answer all the needs put forward thus far? After all, if a person is absent, they won’t be able to use their card to get into the building. I can’t tell you how many times we’ve been asked if our own timesheet system could reconcile data from the building access system. It sounds like a low-effort plan except that it doesn’t often give enough information to be useful to anyone but security. After all, if you didn’t swipe your mag-card on the way into the office today is that because you were a) sick? b) on vacation? c) absent without leave? d) on assignment out of the office? or; e) because you walked in behind a kind person who held the door open for you? It’s impossible to tell and, even if you could, it still doesn’t help the Project Management group with what you did with your time.

When an organization starts looking for time-management systems, the perspective of individuals is to find a system that helps the individual organize the tasks in their day. The organizational perspective is generally to took for a system which can collect actual hours spent by task to determine that the most effective use is being made of the resources available. We call such a system a Project-oriented timesheet.

For a Project-oriented timesheet system to be even deployable, it must provide some key elements:

· The system must have enough functionality to manage the data of the organization yet have and end-user interface that effectively requires no training. You should expect that the large majority of end-users will be looking for any excuse not to fill in their timesheet. “It’s too complicated” is jus too tempting.

· The system must have an ability to lock-down information such as total hours for finance so that these finance-oriented values are not altered without approval yet must still have some “redistribution” functionality which allows project managers to redistribute hours after-the-fact to get them onto the proper tasks and projects when in error.

· The system has to support the organization’s internal hardware, software, operating system and data structure. After all, this will likely be the most deployed data application in the company. It makes no sense to start implementing such a system on a data environment which is contrary to the company standard.

Once you’ve found or written a system which is deployable, your work is not over. All the classic issues that come with deploying an enterprise-wide system will be here in spades. Make sure that some of these elements are on your list for consideration when you make up your implementation plan:

· Get an executive-level product champion. Given people’s general reluctance to fill in timesheets, you can expect to require the authority of someone at the executive level sooner or later. Also, it’s almost a guarantee in most large-sized organizations that along the way you’ll find multiple department-level timekeeping systems in use that some people will be reluctant to abandon.

· Have a plan. I know I keep mentioning this in almost every column but it’s because I see organizations almost every week who still try to implement an enterprise-wide system without a plan. (Um… If I visited your firm last week, I didn’t mean you… Honest!) Once you’ve got a plan, make sure you manage its progress.

· Start small. Over and over I see implementations where every employee is put onto the system on the first day. They’re sometimes successful (mostly not) but the pain you’re in for if you go this way! Start with a core group of users and schedule bringing on the balance week by week once the use of the system is stable. Leave the most reluctant (and unfortunately, sometimes the noisiest) until last.

· Make sure that the goals that this committee sets out are clearly identified. If the need is really for a time and billing system, don’t be looking for just a time and attendance system. You’ll end up spending an enormous effort implementing something that won’t meet the demand.

In the end, the most important analysis is a Return on Investment. The investment of money in the new system is the least significant. The effort to get the entire organization moving in one direction is what costs. Make sure you’ve identified what returns the organization will receive for that effort.