Project management strategy for IS/IT departments--how to successfully manage multiple, concurrent, technology based projects and operational responsibilities
Yana K. Lemann
The general consensus that effective project management is critical to the success of Information Technology projects has infiltrated the IS/IT field with a wealth of information on how to apply project management principles to the ever growing and changing IS/IT industry. But almost every book, seminar, or presentation that has “Information Technology” in its title also has “systems development” or “application development” in the opening lines. Of course there is no argument that the larger the initiative the more it benefits from project management, and large IT initiatives such as those undertaken by IT organizations or IT solution providers have certainly benefited from the project management discipline. From the available literature we have learned the importance of performing detailed user requirements analysis, controlling scope creep, setting more realistic project plans and budgets, and expanding our role and skill sets as IT project managers. The realities of implementing large information systems, developing and marketing software applications, or building international Wide Area Networks have been a great fit to the expanding study of IS/IT projects. But what about IS/IT departments? Those executives who are responsible for providing and supporting technical solutions for the corporate distributed environment with limited resources—can they function in the same project management setting as an IS/IT organization? And what about those organizations that don’t have such executives, where every department can initiate projects to further their individual business needs as they arise with little consideration for the overall information systems strategy of the corporation?
Let’s consider a typical day in a life of a system analyst working for an IS/IT department of a large corporation. You arrive to work to find out that two remote locations are down due to a power outage that occurred the previous night. You begin troubleshooting the problem when your boss calls you into his office to tell you about a very important new project that he needs you to work on. It’s an Oracle-based application that will allow the Purchasing department in your corporation to track all their orders. Your boss relays the business need to you from his previous conversation with the VP of Purchasing and mentions that the Purchasing department has already signed the contract with the solution provider of this application and has coordinated timeframes to begin training in two months. You tell your boss that you will look into it as soon as you have a chance but that, if he remembers, you also have four other projects on your plate with committed time frames. By about lunchtime you resolve your outage problem and begin gathering information about your new Purchasing project when your routine is once again interrupted by another call from the help desk—this time it’s the Payroll department. They have just copied a large file from the mainframe to their server and are getting “out of disk space” messages on their desktops. They can’t delete the file because there is an urgent need to process it today or people won’t get paid on time. You put on your firefighter hat once again, move some files around, change some mappings and you’re back to your projects. You planned for today to begin testing the new Virus Protection package in the lab (something you should have done two weeks ago but just didn’t get a chance to) but it’s now lunchtime and you haven’t even setup your lab environment. You setup the lab and begin the install. Half way through the install your server locks up. You try everything you know for several hours but finally give up. You call technical support just to find out that there is an undocumented patch that may solve your problem and that you may have a possible driver conflict. It’s now 7 p.m., you’ve eaten nothing but a bag of chips, made little to no headway on any of your projects, and managed to acquire a new project with a set deadline over which you have no control. Oh well—there is always tomorrow.
If this scenario sounds at all familiar you’re in the same boat with many IS/IT departments that have to implement projects while putting out fires and performing maintenance and support of both the corporate distributed environment and the technology solutions they put in place. Additionally, because most IS/IT departments don’t generate profit, they largely function as operational units, with little decision-making authority as to which projects to implement and when. When you add this on top of limited resources, predetermined time frames and budgets, cutting edge technologies that don’t often work as described in manuals, poor understanding of project management concepts, and lack of company-wide Project Management initiative, it is no wonder that projects fail.
So what can you do as a manager of an IS/IT department to maintain your systems, provide support and deliver new solutions on time and with maximum customer satisfaction? Embrace project management of course! But neither hiring the most experienced project managers nor following the guidelines of the PMBOK® Guide will in themselves solve the problem. The answer is much more complex and involves an integrated web of changes that have organizational, functional, procedural and project specific impact.
Project Management Context Implications
Depending on your corporation, you may or may not have a corporate project management strategy in place. If you work for a corporation that has embraced “management by projects,” or whose main line of business is defined by the projects it implements, your projects may already be governed by companywide project management, project approval, and project prioritization processes that include you as a corporate project team member while dictating which corporate initiatives should be addressed first. This is increasingly becoming the environment of IS/IT organizations and IS/IT solution providers. Today however, most corporations that house IS/IT departments still operate based on a “functional” organizational model, and for many whose line of business is largely operational in nature and whose survival does not depend on projects, such model still makes the most sense. The outcome is that individual departments are empowered to improve and increase their performance, efficiency, and profitability with no consistent priority across and within departments and no consideration for competing demands for resources across projects. In today’s age of technological advances when most “improvements” translate into technical solutions, this mode of operation has a direct effect on IS/IT departments that are subsequently forced to “react” to project work rather than proactively participating in defining, planning and implementing solutions to meet business needs. The results are often incompatible solutions, unrealistic project deadlines, and resource contention among projects, just to name a few. If this is your situation, consider bringing technology driven projects under one project management umbrella and handling them as a “program” of interrelated projects to meet organizational goals. Since technology projects are often interdependent, are based on the same underlying infrastructure, rely on the same pool of limited resources, and integrate across departmental boundaries, IS/IT departments become the logical leaders in this initiative. This is a little easier said than done since changing corporate organization or business process is never a conflict free endeavor, so be prepared for a battle and be ready to restructure your IS/IT department to meet the challenge. Depending on your company’s internal politics the following bullets may or may not help you with that initiative:
Go for the Big Picture a Piece at a Time
If you can’t get your company to adopt a corporate project management strategy, focus on what you can control which is expanding your role as the information management leader in your organization with the responsibility for overseeing corporate information system initiatives. Don’t be discouraged by the fact that the ideal “big picture” of implementing projects from the top down is not there and don’t expect to turn your corporate boat over night. If you can’t control that “go-live” date the marketing department scheduled for the new customer contact database without your involvement, or if you were never consulted about the dialer vendor your call center just signed a contract with, don’t give up on the details of your involvement in these initiatives. Applying project management principles to that part of the project which is on your plate will still bring you far more benefit than operating within the realm of the above example.
Use Influence, Not Authority; Educate Rather Than Obligate
The best way to bring others on board with your objectives is to familiarize them with your predicament and explain the reasoning and the motivation behind your solutions. If your company is not ready to look at the relationship between the customer contact database the marketing department is implementing and the customer issues initiative underway in the service department, take the time to point out to the respective departments platform incompatibilities between the two systems in case there ever is a need to integrate. Likewise, if a predetermined deadline of one department caused you to be two weeks late on another department’s project, educate both parties to the implications of not including IS/IT in the planning process—tomorrow it could be your project that is slipping.
Lead by Example
Although it is tempting and often best to get everyone’s sign off on your plan and work out as many areas of friction as possible before embarking on the global project management initiative, sometimes the “buy-in” process can be so political, time consuming and non conclusive that the effort is doomed before it ever begins. In these cases it is often better to begin at a place that doesn’t require global consensus and through influence and education work your way up—department at a time, project at a time. Chances are that if you have a successful project management system in place, others will see it’s value and will follow suit.
If you have no project management methodologies in place, don’t expect to be able to lead your company in technology-based projects with no changes to your existing organization or your budget, and don’t expect the change to happen overnight. Without training, additional project management resources, project management tools, time, or a combination of the above, you will not be very successful. Perhaps the most significant changes you can make are to separate project functionality of your IS/IT department from its operational responsibilities, establish a project management methodology and implement a project office. Let’s examine each of these initiatives in a little more detail.
Projects vs. Operational Tasks
The key to any successful project is stability and availability of it’s resources, so to prevent your project resources from continuously being pulled off of projects to address operational responsibilities, segregate your resources into separate resource pools. Begin by defining what requests are operational in nature and what requests are projects. Although the PMBOK® Guide’s definition of a project is a good starting point, and most IS/IT initiatives fall well within this framework, many IS/IT departments still find themselves in a quandary trying to resolve requests that fall into a gray area between projects and operations. For example, would an effort to restructure login scripts across the enterprise or a need to upgrade disk space on a production server be an operations task or a project? Some would argue that these are distinct endeavors undertaken to create a new distinguished way for users to login to the network or a potentially new server configuration and thus should be treated as a project, while others may argue that it is an ongoing component of network/server maintenance and thus should be treated as an operations task. Whichever way you choose to view the above example, it is important to keep in mind why you are separating operations from projects and to take into account the effects of project prioritization and resource availability on your organization of choice. When a new request comes in, consider whether it can be prioritized along with all other project work or if the need is immediate with possible consequences to the stability of a particular system or the distributed environment. If you treat immediate needs as projects, although they may be unique and temporary in nature, because of limited resources, you will always interrupt scheduled project work with unplanned requests. If however, you categorize them as operational tasks, because of the same limitation of resources, you will always interrupt problem resolution and troubleshooting efforts with unique endeavors. For those gray areas the solution is often a delicate balance that may require you to decide on a case-by-case basis which classification will have a net minimal impact on your resource allocations and delivery dates across both functions.
Once you have conceptually separated your functions, focus on implementing the organizational structure necessary to support the concept. The best alternative is to implement the separation at both organizational and functional levels to avoid potential conflict within any one technical area and to facilitate cross training and a formal project closure/turnover process. Because many IS/IT departments tend to think within the realm of the functional technology units that comprise the department, the immediate tendency may be to dedicate certain resources within each functional area to operational responsibilities. This of course may also be the only alternative if there are only one or two available resources to speak of. This structure however, while preserving the unity of the technical unit, can have an opposite affect on functional objectives. Operational tasks are driven by a different set of objectives, performance and quality measures from project work and thus should be setup as separate organizational units. While requiring a fair amount of cross training and careful employee selection to ensure that both areas are staffed adequately on the front end, by establishing an internal as well as an external project customer, this structure also promotes and ensures adequate technical documentation and additional quality assurance measures that would be very difficult to implement without this organizational division. You will still need to allocate a certain portion of the project analysts’ time to resolve escalated issues from past project implementations, but as your cross-training and project closure processes develop and improve, that time will become minimal.
Once you have successfully created a dedicated pool of project resources, focus on creating a project office to drive your project management initiatives. Implementation of the project office does not have to be an expensive undertaking that involves hiring project gurus that have managed multimillion-dollar projects and know all the nuances of conflict resolution, risk mitigation, and procurement. (You may build to this depending on how detailed and extensive you get with your project management efforts, but this is certainly not a requirement.) The most important step is to designate a resource or resources that will facilitate development and implementation of your project management strategies, methodologies and processes and be responsible for ensuring that everyone involved adheres to them. Because most IS/IT departments are divided into functional areas such as Web development, application development, database administration, and network engineering, the project office will guarantee that projects are planned, controlled, implemented, documented, and reported on in a standard manner across all groups. Ideally, the project office should be given either expressed or implied authority to affect the business process as it pertains to the project life cycle and should exist at an organizational level that does not foster conflict between functional areas. Although it is possible to approach the initial inception of the project-oriented structure by designating functional managers as project managers or by hiring project managers to manage individual IS/IT projects without building a project office, such a resolution can have compounding effects on the IS/IT department’s ability to manage its projects as a “program.” This is especially evident in projects that cross IS/IT department’s internal functional boundaries and, on a higher level, in projects which cross-corporate boundaries. With every functional manager and/or project manager potentially approaching projects from his or her own methodology with no fixed and controlled direction for the unified intent, the consequences can range from poor customer impressions to project delays to deep frictions that can leave you spinning wheels and potentially impairing the whole project management integration endeavor.
Exhibit 1. Project Breakdown in IS/IT Departments
Resource vs. Project Centric Management Strategy
An important part of implementing a project office is deciding what your project methodology will be and who will run your projects. In order to do that successfully, you must first examine the number and the nature of projects on your plate and determine which areas of your current operation are in most need of project management. Traditionally, a typical IS/IT department will have three main types of projects—internal projects that either enhance or correct distributed system stability, availability, usability, or cost; external companywide initiatives in which IS/IT is either a small or a large player; and departmental request. Projects within each of these three main areas can range from complex integrated technical solutions that usually involve resources from all functional divisions of IS/IT to simple implementations that involve only one functional area. The number of projects can range from tens to thousands depending on the size of the corporation with the majority of projects never spanning functional boundaries, involving simple, straightforward standard implementations and requiring one or two resources. Exhibit 1 illustrates project breakdown of a typical IS/IT department, with the large colored circles representing project breakdown across corporate boundaries and smaller circles representing project breakdown across internal IS/IT functional boundaries.
When pegged against a limited number of resources, which is usually a significant limitation of most IS/IT departments, this breakdown poses a theoretical question as to which management strategy will yield more successful results—management by projects or management by resources. The answer depends on the size of your resource pools and on your ability to obtain additional necessary resources. In an ideal situation, where project teams can be built from large resource pools, and projects’ critical paths can be crashed with additional resources, as needed, project centric approach makes the most sense. In such a scenario, not taking into account other resource limitations, availability of specific resources has little impact on the critical path of the project since assigned resources can easily be substituted with other viable alternatives. Projects can be planned based on “dummy” resources with little consideration for critical paths of other concurrent projects. This however is rarely a reality of IS/IT departments, which, in addition to being inundated with project requests, are almost always constrained by resources and budgets. For most IS/IT departments, building hundreds of project teams that all comprise of the same set of resources is impractical and offers no benefits. Likewise, managing the critical path of project “A” where your resource’s availability for a task is directly dependent on his/her completion of another task for project “B,” without also looking at the critical path of that project leads to erroneous conclusions and incorrect decisions. Those IS/IT departments that ignore their resource limitations and continue to function in a project centric mode often find their resources over-allocated and working 60-80 hours per week to meet unattainable deadlines. Often, the best alternative for IS/IT departments is to adapt a resource centric project management approach while still focusing on the timeline driven milestones of each individual project. This means enhancing traditional project management scheduling practices which center around “time driven” critical paths with effort estimating tools that center around “resource driven” histograms. It also means gathering historical effort statistics, using those statistics to estimate future planned effort levels, and monitoring current and future resource availability based on those effort levels.
Exhibit 2. Effect of Unscheduled Work on Scheduled Projects
Project Managers vs. Functional Managers
A logical subsequent question to “which project strategy is most suiting to an IS/IT department” is “who should run the projects—project managers or technical managers”? This answer depends not only on whether your corporation has embraced project management on a global level, but also on the internal and external integration requirements of your projects. On an internal level, once operational resources are separated from project resources, the project units of IS/IT departments become fully “projectized” entities with roughly 90% of resources dedicated to project work. On a corporate level, however, unless global project management is in place, this “projectized” entity is constrained by “functional” corporate contexts. This picture is complicated even more if only some and not all of the internal IS/IT technology areas are “projectized.” If your corporation has embraced global project management, if even in a form of a “weak matrix,” your solution is dictated to you by the choices of your corporation. If however, you are a corporate project management island, you must dig deeper. One solution may be to focus on when is project management needed the most. Integrated efforts, either within the IS/IT department or across corporate departmental boundaries, either large or small, benefit the most from having a project manager or a project coordinator drive the project by centralizing all project communication, planning, and controlling efforts. For IS/IT departments that have always operated in a “functional” model and are now moving to a “projectized” model, the role of a project coordinator or a project manager takes on additional significance because it eliminates political project control battles that focus on non-project impacting issues and jeopardize project deliverables. However, for projects that never span functional or organizational boundaries and involve one or two resources, the benefits of coordination, negotiation, and mitigation are limited and it becomes difficult to justify all the skills, experience, and salaries that come with seasoned project managers. For these initiatives, the best solution is to have the functional managers whose resources will be executing the project drive the project. Although this may cost you more up front to train your technical resources who are accustomed to focusing on tasks to begin focusing on projects, you can save on long term project manager costs. A third alternative is to maintain project control within the hands of functional managers, regardless of the nature of the project, while assigning project coordinators to each functional manager to alleviate the administrative burden of project management. This should only be considered as a starting point for moving along the project maturity spectrum since it fosters rather than resolves communication uncertainties, functional frictions, control conflicts and duplication of effort.
While the organizational and functional changes build a framework within which IS/IT departments can begin to focus on projects, this framework cannot sustain without processes. Process is what moves initiatives from point A to point B and your project life cycle will be the greatest influence over the processes that surround moving your projects from their inception to their completion. The procedural changes described below surround those principles that will give you the biggest buck for your money in transcending the organizational and functional limitations described above.
Exhibit 3. Systematic and Quantitative Prioritization Methodology Weighted Average Model
Project Management Process Implications
Single Entry Point for All Project Requests
Probably the most important and visible process change that you can make as a manager of an IS/IT department is to mandate that that all project requests that will require IS/IT resources go through one single point of entry. This can be either a form on your intranet that is linked to a project request database or even a manual paper solution, but it must be complied with without exception, whether the initiative is generated by an external department, or an internal technical group. The benefits of the single entry point for all requests are numerous. First and foremost this process will identify and document all initiatives on your plate so that you will have a starting point for your project process and for gathering user requirements and planning before resources begin actual work on the project. It will eliminate the “broken telephone” syndrome and communication gaps that occur when information is passed on from one person to another in search of the right project resource. It will provide your corporate customers with a single point of contact for initiating projects so that they are no longer left guessing as to whether they should contact the Web group, the application group or the client/server technologies group to have their Web-based application deployed to the enterprise. It will create an even ground and a foundation for the prioritization process by placing all project requests on an equal footing and will ensure that the real needs of your corporation are assessed before a solution is suggested. Without this change, you will continue to operate in a world of chaos and constant project slippage, always back paddling to try to catch up with what your resources are doing and why. Exhibit 2 illustrates the effect of non-scheduled work on resource allocation levels and project slippage.
Of course if not succeeded by other processes, the single entry point in itself will give you little results short of a list of all project request for the week, month, etc., so let’s look at what should happen next.
Project Prioritization Process and Methodology
Once you have your list of outstanding project requests, how do you determine which project will happen next and based on what criteria do you make your decision? Everyone must prioritize but will your prioritization be based on the date the project request was received and handled on a FIFO basis, or will you focus on those projects whose requestors have the most political pull or scream the loudest? Because your current workload will continuously be inundated with new project requests, your prioritization model should be a combination that will allow you to continue working on started initiatives with minimal interruption yet provide you with a mechanism of escalating urgent initiatives to the front of the list.
If you currently have nothing in place for formal prioritization, begin by considering all your “in-process” initiatives as having the highest priority rating. This will enable you to finish all your current work with little interruption. Next, prioritize all your known requests and schedule them out based on their priority rating. Finally, determine a threshold for all future potential requests at which the project will be allowed to move in front of other already scheduled work. Sounds simple, but prioritization is in fact a very labor intensive, time-consuming process both to develop and to maintain.
First you must develop the model itself. Whatever the format, your model should be a reflection of your corporate objectives and should compare projects against each other in terms of how they align with the corporate strategy. To the greatest degree possible, it should be objective and leave little possibility for subjective interpretations and arguments. You must obtain corporate buy-in to the model and all departments that could ever have technological needs should feel comfortable with the results of the model, whether calculated by the IS/IT department itself or by an external project steering committee. One possibility is to use a combination of dimensions which best represent the factors your company would use to determine the importance of an initiative, for example, “business need,”“cost/benefit,”“effort,”“scope,”“duration,” etc. You would then assign each dimension a weight based on how much you would like that dimension to affect the final outcome so that all dimensions when added together would equal to 1 or 100%. For more objective results, each dimension would contain predetermined values representing the full spectrum of possible outcomes of each dimension, and the values would be further weighed against each other with the weights ranging from 0 (no impact) to 10 (greatest impact). The total score of the project would be obtained by adding across all dimensions a multiple of the value that best describes each dimension and the weight of that dimension. Projects with higher scores across all dimensions and values would be prioritized above those with lower scores. As a final step in your model development process you will need to run a myriad of projects through the model to ensure that specific values and weights accurately represent reality, and make adjustments as needed. Exhibit 3 is a visual representation of a possible prioritization model.
In addition to developing and testing the model, you will need to develop and test the process. You will need to determine if, based on your organizational environment, your corporation will require an external to IS/IT steering committee to drive the project prioritization process, or if that initiative will be able to be handled from within. You will need to decide what information will be required to make decisions and will need to develop documentation and procedures that will provide that information to the deciding entity. Finally, because the project list will always be dynamic, changing from week to week with new requests, you will need to establish a mechanism for viewing current and forecasted resource allocation levels across IS/IT and a reevaluation process that will allow the current and forecasted workloads to be reevaluated based on new requests.
Project Specific Implications
As you move through organizational and procedural changes, you can never lose sight of the project itself and the following suggestions illuminate the most common project challenges IS/IT departments face today.
Control Your Scope and User Requirements
Scope creep is an old project management dilemma, but it is especially prevalent in technology based projects because technology projects center around efficiency gains and gaining efficiency implies doing things differently from the way they had been done in the past. In most cases, especially those where efficiency gains are tied to the business process, such changes take time to evolve. You can install a system in a day, but integrating that system with the way you do business can take months and during that integration effort you can almost guarantee that needs will be reassessed, processes redeveloped and user requirements redefined. In some instances, the technical solution will be open enough to accommodate these changes, but in some cases the solution will have to be enhanced, expanded and sometimes even replaced. Another reason for scope creep is that modern technology advances conceal many unknowns that can only be revealed through R&D efforts that don’t occur until after the initial scope of the project is defined. To get around these dilemmas consider requiring that any significant changes in scope be formulated into a separate project and prioritized with the rest of the workload. Also, for projects that involve large R&D efforts, try to set your final scope at the end of your design phase to minimize the number of scope changes. Finally, make sure that, when setting your scope, you have identified the true user requirements and business needs of your clients. This is especially important in corporations where individual departments are empowered to independently search for their own technology solutions. In these situations, the request is almost always to install a preselected application rather than to satisfy a particular business need. If, in turn, you will define your scope in terms of technical solutions rather than user requirements and business needs, as other solutions are investigated and suggested, your scope will change.
Plan Technology Projects a Step at a Time
When asking your IS/IT department how long it will take them to deliver a technical solution to your business need, how many times have you heard “I can’t tell you.” Although one part of this “I can’t tell you” stems from the previously discussed lack of dedicated project resources and project prioritization, the other part of it stems from the fact that in many cases your IS/IT department really doesn’t know. Let’s take for example a request from a user to provide him or her with up to date auto loan rates across the state. Although the user requirement is clear, implementation time can range from one day if an auto loan rate service is available via the internet, to one month if this information can be made available via lease line connectivity to a third-party vendor, to three months if a client/server application needs to be installed and linked to a third-party vendor for large auto updates. For this reason, it is best to plan technology projects that involve R&D one step at a time. If you’re trying to enhance the functionality of your hubs across the enterprise, how can you tell when the project will be completed when the difference between remotely patching the hubs and replacing every hub in the enterprise can be six months and thousands of dollars. R&D intensive projects should be planned twice—once for the R&D effort to minimize prolonged playing in the sandbox and once for the actual implementation after the design has been approved and the solution can begin to be built and rolled out. When forecasting your resources, continue to estimate and update the implementation effort based on historical project data and on the latest results of the R&D effort and be sure to educate your customers and set their expectations to be in line with what you can deliver.
Plan Before Beginning Work
This is probably the most difficult habit to overcome in an environment where there are no formal project prioritization processes. Because technology is new and ever changing, technical resources tend to want to jump on the bandwagon as soon as they can so that they can learn new technologies. As a result, new initiatives are started at a much higher rate than old ones are completed. Far more projects stay open with no steady progress, creating an increased need for additional communication, possible deliverables, and prolonged R&D efforts that would otherwise not exist until the project was ready to be actively worked on. Furthermore, timelines and baselines are implicated since some activities are progressed before a timeline is created or a baseline set, making it very difficult to accurately forecast project delivery or measure project progress. In your evolution toward a project management culture, this is probably the second most important checkpoint you can implement next to a single entry point for new projects.
Minimize Uncertainties You Can Control and Plan for the Ones You Can’t
Technology projects carry a lot of uncertainty with them. They depend on availability of viable solutions, large R&D efforts, seamless integration, third-party delivery dates and the fact that everything will work according to the user manual and the installation guide. Those of you who have managed technology projects or who have installed software on their home PCs that made their computers lock up, know how well everything in the IT world works together. As a project manager you have control over some of these uncertainties and it is your responsibility to try to eliminate as many of them as possible for your project. If your most significant project slippage results from external milestones, raise the stakes your external groups have in timely project completion, strengthen your existing external relationships, and ensure that all stakeholders are aware of external milestones, their status and their impact on the project timeline. If an external milestone is an unknown, it is better to estimate an approximate delivery date than omit the milestone altogether or record it only when a clearer delivery date is obtained. If, on the other hand, your most significant project slippage results from technical difficulties during implementation, implement a strong piloting methodology that will minimize the number of problems encountered during implementation. Finally, if you can’t control the uncertainty, make sure that you schedule in float. Because technology is environment sensitive, unless you’re implementing a standard solution in a standard environment, assume that even proven solutions will not work the first time without additional tweaking.
In conclusion, this paper has tried to outline some of the issues faced by IS/IT departments today in trying to integrate Project Management principles and methodologies into its culture in order to gain control of its project and operational loads. It has presented many problems and has offered some suggestions that can serve as starting points for resolving those problems. As a last word of advice remember not to try to implement everything at once and evaluate and customize solutions to your particular political and business environments. Focus on your biggest issues first and be flexible—good luck!
Proceedings of the Project Management Institute Annual Seminars & Symposium
September 7–16, 2000 • Houston,Texas,USA