12 Information Systems Project Management
Learning Objectives
- Define IS project management.
- Understand the importance of IS project management in businesses.
- Identify and describe key concepts in IS project management.
- Demonstrate familiarity with tools and techniques in IS project management.
Definition of Information Systems Project Management
Information Systems (IS) Project Management is a specialized branch of project management that focuses on the oversight and coordination of all aspects related to the development, implementation, and maintenance of information systems. Information systems can include anything from business process management systems and customer relationship management systems to data warehouses and enterprise resource planning systems. IS Project Management involves the application of knowledge, skills, tools, and techniques to IS-related project activities to meet the project requirements. This includes a wide range of tasks, such as defining project goals, planning project activities, assembling project teams, assigning tasks, monitoring progress, managing changes, and resolving issues that arise during the project. IS Project Management shares many similarities with general project management. Both involve managing the triple constraint of time, cost, and scope, as well as quality, risk, and stakeholder satisfaction. However, there are some unique characteristics and challenges associated with IS Project Management:
Technological Complexity: IS projects often involve complex technology, which can be challenging to manage. Project managers need to have a good understanding of the technology being used, its capabilities and limitations, and how it can be best utilized to meet the project goals.
Rapid Technological Change: The field of information systems is characterized by rapid technological change. This requires IS project managers to be adaptable and flexible, and to keep up to date with the latest technologies, methodologies, and best practices.
Integration with Business Processes: IS projects are usually not standalone endeavors. They need to be integrated with existing business processes and systems, which adds an additional layer of complexity. This requires IS project managers to have a good understanding of the business and its processes, in addition to technical knowledge.
User Involvement: User involvement is critical in IS projects. The success of an IS project often depends on how well the system meets the needs of its users. Therefore, IS project managers need to ensure effective communication and collaboration between the project team and the users throughout the project.
Security and Privacy: IS projects often involve sensitive data, which needs to be protected. IS project managers need to ensure that appropriate security and privacy measures are in place.
In conclusion, IS Project Management is a complex and challenging field that requires a unique combination of technical knowledge, project management skills, business acumen, and people skills. However, with the growing importance of information systems in today’s digital age, it is also a field that offers great opportunities for those who can successfully navigate its challenges.
Importance and Role of IS Project Management in Businesses
In today’s digital age, Information Systems (IS) play a crucial role in the operation and success of virtually every business. They support a wide range of business functions, from communication and decision-making to process automation and data analysis. However, implementing an IS project is a complex and challenging task that requires careful planning, coordination, and management. This is where IS Project Management comes into play. IS Project Management is essential for several reasons:
Ensuring Alignment with Business Objectives: IS projects should support the strategic objectives of the business. IS project managers play a crucial role in ensuring that the project aligns with these objectives, from the initial selection and planning of the project to its execution and closure.
Managing Complexity: IS projects often involve complex technology and need to be integrated with existing business processes and systems. IS project managers help manage this complexity, ensuring that all aspects of the project are coordinated and that the project stays on track.
Controlling Costs and Schedule: IS projects can be expensive and time-consuming. Without effective project management, projects can easily go over budget and schedule. IS project managers help control costs and schedule by planning and monitoring the project’s progress and making necessary adjustments.
Managing Risks: IS projects involve many risks, from technological risks (such as system failures or security breaches) to organizational risks (such as resistance to change). IS project managers help identify, assess, and manage these risks to prevent them from derailing the project.
Ensuring Quality: The success of an IS project is not just about completing it on time and within budget, but also about delivering a system that meets the needs of its users and delivers the expected benefits. IS project managers play a key role in ensuring the quality of the project, from defining quality requirements to overseeing testing and quality assurance activities.
Facilitating Change: IS projects often involve significant changes, not just in terms of technology, but also in terms of business processes and ways of working. IS project managers help facilitate these changes, ensuring that they are managed in a structured and systematic way.
In conclusion, IS Project Management plays a crucial role in businesses. It helps ensure that IS projects are successfully delivered, providing the foundation for businesses to leverage information systems to improve efficiency, effectiveness, and competitiveness.
Project Selection
In the dynamic landscape of today’s business environment, organizations are constantly faced with the challenge of allocating their limited resources effectively to ensure sustainable growth and competitiveness. The decision to undertake a particular project is a strategic one, as it involves a careful evaluation of opportunities, risks, and alignment with organizational goals. This section delves into the fundamental aspects of why and how businesses engage in project selection, exploring the strategic considerations and methodologies employed in this critical decision-making process.
Project Selection: Criteria and Techniques
Project selection is the process of evaluating potential projects and choosing the ones that best align with an organization’s strategic objectives and resource availability. It is a critical first step in project management, as the selection of an inappropriate project can lead to wasted resources and missed opportunities.
There are several criteria that organizations typically consider when selecting projects:
Strategic Alignment: The project should align with the organization’s strategic objectives. For example, if an organization’s strategy is to improve customer service, projects that enhance the customer experience would be prioritized.
Potential Return on Investment (ROI): The project should offer a sufficient return on investment. This includes not only financial returns, but also other types of returns, such as improved customer satisfaction or increased operational efficiency.
Risk: The project’s risks should be assessed and considered. This includes both the risk of project failure and the risk associated with not undertaking the project.
Resource Availability: The organization must have the necessary resources (e.g., personnel, equipment, budget) to execute the project.
There are several techniques that can be used to evaluate and select projects based on these criteria:
Scoring Models: Scoring models involve assigning weights to different criteria based on their importance, and then scoring each project against these criteria. The scores are then multiplied by the weights and summed to give an overall score for each project.
Decision Trees: Decision trees are graphical models that represent different choices, outcomes, and probabilities. They can be used to evaluate complex project selection decisions that involve uncertainty and risk.
Cost-Benefit Analysis: Cost-benefit analysis involves comparing the costs of a project (both direct and indirect) with its potential benefits (both tangible and intangible). Projects that offer the highest net benefits or the highest benefit-cost ratio are typically selected.
Portfolio Management: Portfolio management involves evaluating and selecting projects based on how they fit into the organization’s overall project portfolio. This approach considers not only the merits of individual projects, but also how they collectively contribute to the organization’s strategic objectives and balance its risk profile.
Net Present Value (NPV) and Internal Rate of Return (IRR): These are financial analysis methods used to estimate the profitability of potential projects. NPV calculates the present value of future cash flows, while IRR calculates the discount rate that makes the NPV of all cash flows equal to zero. Projects with a positive NPV or an IRR that exceeds the required rate of return are typically considered favorable.
The choice of criteria and techniques depends on the specific context and needs of the organization. It’s also important to note that project selection is not a one-time activity but should be a continuous process that is revisited as conditions change and new information becomes available.
Traditional or Predictive Project Management
Before diving into the specific phases of an Information System (IS) project, it is important to understand the overarching framework often used to manage them. Historically, the most common approach is the Traditional or Predictive project management framework—frequently referred to as the Waterfall methodology.
As the name suggests, a predictive framework operates on the assumption that the project’s requirements can be clearly defined, analyzed, and planned at the very beginning. In this model, the project progresses in a linear, sequential fashion. Much like a waterfall flowing over a series of drops, once the project moves from one stage (such as Design) to the next (such as Development), it is difficult and costly to “flow” back up to make changes.
Core Characteristics of the Predictive Approach
-
Fixed Scope: The primary goal is to “Plan the work and work the plan.” Detailed documentation is created upfront to ensure everyone agrees on the final system’s look and functionality before a single line of code is written.
-
Sequential Phases: Each phase has a distinct start and end point. A phase usually cannot begin until the “deliverables” from the previous phase have been formally reviewed and approved (a process often called a Stage Gate).
-
Minimal Change: Because the budget and schedule are built around a specific plan, changes requested mid-project are handled through a rigorous “Change Control” process to prevent the project from spiraling out of scope.
While modern software development often leans toward more flexible “Agile” methods (which we will explore in the next chapter), the traditional predictive framework remains the gold standard for large-scale Information System projects where the cost of error is high—such as upgrading a city’s emergency response database or migrating a global bank’s core financial ledger. In these cases, the discipline of thorough upfront planning is essential for success.
The 5 Phases of an Information System Project
The project management life cycle provides a structured framework for guiding a project from its initial concept to its final completion. As illustrated in the image above, this cycle is broken down into five distinct but interconnected phases.
Here is a brief overview of each phase:
- Initiating – This is the starting point where the project is defined at a high level. The business need is identified, feasibility is assessed, and the project is formally authorized to begin.
- Planning – Crucial for project success, this phase involves creating a detailed roadmap. The project’s scope, schedule, budget, resources, and risks are all defined to guide the upcoming work.
- Executing – This is where the plan is put into action. The project team performs the actual work, building the deliverables and creating the product or service defined in the planning phase.
- Monitoring & Controlling – As shown in the image looping around the Executing phase, this is an ongoing process of tracking performance against the plan. It involves reviewing progress, managing changes, and ensuring quality standards are met to keep the project on track.
- Closing – The final phase brings the project to a formal conclusion. The completed product is handed over to the stakeholders or operations team, final documentation is filed, and the project is officially signed off.
Project Initiation Phase
The Project Initiation Phase is the formal start of the project. At this stage, a project is often just an idea or a response to a specific business need. The overarching purpose of this phase is to provide clarity and direction, answering fundamental questions about why the project is necessary, what it aims to achieve at a high level, and who is involved.In the PMI framework, Initiation is intentionally streamlined. It is not about building the system or creating a detailed schedule; rather, it is about establishing a solid foundation and gaining the formal “green light” to invest time and resources into the project.
Key Objectives of Initiation
- Define High-Level Objectives: Identify the core business problem or opportunity. While detailed “SMART” criteria are often refined in the Planning phase, Initiation establishes the primary goals and boundaries (high-level scope) to ensure the project aligns with the organization’s strategic vision.
- Identify Stakeholders: This is a critical PMI process. The project manager must identify all individuals or organizations impacted by the system (users, IT staff, executives, or external vendors). Understanding their influence and expectations early prevents significant friction later.
- Determine Strategic Feasibility: Based on the Business Case (often developed just prior to Initiation), the organization confirms that the project is technically and economically viable before committing significant capital.
The Project Charter: The Project’s “Birth Certificate”
The most vital output of this phase is the Project Charter. This document is the bridge between the high-level business need and the tactical project work.
The Importance of Authorization: The Project Charter is not a technical manual; it is a formal document signed by the Project Sponsor. Its primary purpose is to formally authorize the existence of the project and grant the Project Manager the authority to apply organizational resources to project activities. Until the Charter is approved, the Project Manager technically has no authority to build a team, spend the budget, or move into the Planning phase.
Transitioning from Initiation to Planning
A common misconception is that the project team is fully assembled or the schedule is finalized during Initiation. According to PMI, these are Planning or Executing activities. On completion of the Initiation phase, the business reaches a “Stage Gate.” With the Charter and Stakeholder Register in hand, leadership can decide whether to:
- Proceed: Move into the detailed Planning phase.
- Modify: Change the high-level scope and re-evaluate.
- Shelve: Drop the idea if the initial risks or costs appear too high.
By ensuring these items are rigorously completed, Information Systems project managers lay a structured foundation. This prevents “false starts” and ensures that the detailed planning to follow is built on a sanctioned and clear business mandate. Following the formal authorization of the project in the Initiation phase, the project moves into its most intensive intellectual stage: Project Planning.
While Initiation answers the “Why,” the Planning phase is dedicated to answering the “How.” In an Information Systems (IS) context, this is where the abstract goals of the Project Charter are translated into technical requirements, database schemas, and line-item budgets.
The Project Planning Phase
The Project Planning Phase is the process of defining project objectives and the roadmap for achieving them. According to PMI, this phase is not a single event but a collection of processes that result in the Project Management Plan.
For IS projects, the risk of “Scope Creep” (uncontrolled changes or continuous growth in a project’s scope) is high. Therefore, the primary goal of this phase is to create baselines—fixed points of reference against which future progress can be measured.
Key Objectives of Planning
-
Define Detailed Scope: The high-level goals from the Charter are broken down into a Work Breakdown Structure (WBS). This is a hierarchical decomposition of the total work to be carried out by the project team.
-
Develop the Schedule: Project managers identify the specific activities required to produce the deliverables and determine their dependencies. This often results in a Gantt Chart or a Network Diagram identifying the “Critical Path.”
-
Determine Budget and Resources: Planning involves estimating costs for hardware, software licenses, and human labor. This establishes the Cost Baseline.
-
Risk Management Planning: Unlike the high-level risks identified in the Charter, this phase involves a rigorous Risk Register. For an IS project, this includes planning for data breaches, server downtime, or integration failures with existing legacy systems.
-
Quality and Communication: This phase defines the “Definition of Done” (Quality) and determines who needs what information, when, and through which channel (Communication).
The Output: The Project Management Plan
The final output of this phase is the Project Management Plan. This is a comprehensive document that integrates all subsidiary plans (Scope, Schedule, Cost, Quality, Risk, etc.).
The Importance of Baselines: Once the Project Management Plan is approved by stakeholders, the Scope, Schedule, and Cost become Baselines. Any deviations from these baselines during the Execution phase must be handled through a formal Change Control process. This ensures that the project remains disciplined and accountable.
Transitioning to Execution
The Planning phase typically concludes with a Kick-off Meeting. While a small internal meeting may have happened during Initiation, the Planning Kick-off is the formal transition where the “Blueprints” are handed to the technical team to begin building the system.
Once the blueprints are finalized and the baselines are set, the project moves into the Project Execution Phase. This is typically the longest and most resource-intensive stage of the project life cycle. In an Information Systems project, this is the “build” phase where the code is written, hardware is installed, and the system begins to take a physical or digital form.
While the Planning phase was about the Project Manager’s administrative skills, the Execution phase is about leadership, coordination, and technical production.
The Project Execution Phase
The purpose of the Execution phase is to carry out the work defined in the Project Management Plan to satisfy the project’s requirements. For an IS manager, this means coordinating the technical team (developers, network engineers, database administrators) to ensure they are building exactly what was approved during the Planning phase.
Key Activities in Execution
-
Managing People and Resources: The PM must acquire and develop the project team, ensuring everyone has the tools and access they need (e.g., server permissions, software licenses) to do their jobs.
-
System Development (SDLC Integration): This is where the technical “heavy lifting” occurs. Activities include:
-
Writing and documenting code.
-
Configuring software modules.
-
Setting up server environments and network infrastructure.
-
Database construction and initial data migration.
-
-
Quality Assurance (QA): Distinct from “testing” the final product, QA is the process of ensuring that the processes used to build the system are being followed correctly. It focuses on preventing defects rather than just finding them.
-
Managing Stakeholder Engagement: During execution, stakeholders often get “nervous” or change their minds. The PM must manage these relationships to ensure the project maintains its focus and does not drift from its original purpose.
Key Outputs of Execution
The primary output of this phase is the Deliverable, but there are other critical “by-products” as well:
-
Project Deliverables: The tangible components of the Information System—such as a beta version of an application, a configured CRM, or a new cybersecurity protocol.
-
Work Performance Data: Raw data on the status of the project (e.g., “The developers have completed 45 out of 100 modules”).
-
Change Requests: As the system is built, the team may realize a planned feature won’t work or a stakeholder may request an update. These requests are “kicked back” to the Monitoring and Controlling phase for review.
The Project Manager’s Role: The Conductor
In an IS project, the PM often acts like the conductor of an orchestra. They may not be the ones writing every line of code, but they are responsible for ensuring the “developers,” “designers,” and “users” are all playing from the same sheet music. This requires constant communication and a high level of problem-solving to remove “roadblocks” (such as a delayed hardware shipment or a bug in a third-party API).
While listed as the fourth phase, Monitoring and Controlling is unique because it does not happen after execution—it happens simultaneously with it. If Execution is the act of driving the car toward a destination, Monitoring and Controlling is the dashboard and the steering wheel. It allows the Project Manager to see if the car is running out of gas (budget), drifting off the road (scope creep), or running behind schedule.
The Project Monitoring and Controlling Phase
The primary purpose of this phase is to track, review, and regulate the progress and performance of the project. It involves identifying any areas in which changes to the plan are required and initiating the corresponding changes.
In Information Systems projects, where technical complexities can quickly lead to “scope creep” or “feature creep,” this phase is the project manager’s primary defense against failure.
Key Activities in Monitoring and Controlling
-
Comparing Actual vs. Planned (Variance Analysis): The PM regularly compares current progress against the Baselines established in the Planning phase.
-
Is the database 50% complete as scheduled?
-
Are we still within the $50,000 licensing budget?
-
-
The Triple Constraint (The Iron Triangle): IS managers must constantly balance Scope, Time, and Cost. If the client wants to add a new feature (Scope), the PM must determine how that will impact the deadline (Time) and the budget (Cost).
-
Quality Control (Testing): While Quality Assurance (in Execution) focuses on the process, Quality Control focuses on the product. In an IS project, this involves:
-
Unit Testing: Does this specific piece of code work?
-
System Testing: Do all the pieces work together?
-
User Acceptance Testing (UAT): Does the system actually do what the user needs?
-
-
Integrated Change Control: This is the formal process for approving or rejecting changes. In IS, stakeholders often ask for “one small tweak.” The PM must ensure every change is documented and approved so it doesn’t derail the project.
Key Outputs of Monitoring and Controlling
-
Work Performance Reports: Status dashboards, burn-down charts, or “Green/Yellow/Red” status reports that tell stakeholders how the project is doing.
-
Approved Change Requests: Documentation that officially updates the Project Management Plan to include new requirements or adjusted timelines.
-
Project Forecasts: Estimates of when the project will actually finish and how much it will actually cost based on current trends.
The Project Manager’s Role: The Guardian of the Plan
In this phase, the PM acts as a gatekeeper. They must be comfortable saying “No” to unauthorized changes while being flexible enough to adapt the plan when legitimate issues arise. Without rigorous monitoring and controlling, IS projects often suffer from “Death by a Thousand Cuts”—small, unmanaged delays and additions that eventually lead to total project failure.
The final phase of the project lifecycle is Project Closing. In many Information Systems projects, there is a temptation to “just stop” once the software goes live. However, according to PMI, a project is not complete until it has been formally closed.
This phase ensures that all loose ends are tied up, the system is successfully transitioned to the permanent IT operations team, and the organization captures knowledge that will make the next project even more successful.
The Project Closing Phase
The purpose of the Closing phase is to formally complete the project and all its components. This includes finalizing all activities across all process groups to formally close the project or a project phase.
In the world of IS, this is the moment the “Project” (a temporary endeavor) becomes “Operations” (the day-to-day running of the system).
Key Activities in Closing
-
Final Product Handover: The project manager ensures that the final Information System meets the requirements and is formally accepted by the customer or sponsor. This usually requires a signed User Acceptance Testing (UAT) document.
-
Transition to Operations: The project team hands over the “keys” to the IT Operations or Support team. This includes transferring technical documentation, troubleshooting guides, and administrative access.
-
Administrative Closure: This involves updating all project records, ensuring all contracts with external vendors (like cloud providers or software consultants) are settled and closed, and archiving all project documentation.
-
Lessons Learned: This is a vital PMI best practice. The team meets to discuss what went well, what went wrong, and what should be done differently next time. For an IS project, this might include discussing a specific bug that caused delays or a vendor that performed exceptionally well.
-
Releasing Resources: Team members are officially released from the project to return to their functional departments or move on to new projects.
Key Outputs of Closing
-
Final Product/Service Transition: The live, operational Information System now under the care of the maintenance/operations team.
-
Lessons Learned Repository: A formal document or database entry that captures the team’s experiences for the benefit of future IS projects.
-
Final Project Report: A summary of the project’s performance, including whether it met its scope, schedule, and budget targets.
-
Archived Project Documents: All code repositories, design documents, and meeting minutes are stored in a secure, accessible location for future reference.
The Project Manager’s Role: The Archivist and Diplomat
During Closing, the PM ensures that the project ends on a high note. They must ensure that the users are satisfied, the technical support team feels prepared to take over, and the project team feels their hard work has been recognized. A project that “limps” to the finish line without a formal closing often leaves the organization with “technical debt” and confused users.
Summary
In this chapter, the focus is on establishing a foundational understanding of the key principles and practices essential for effective traditional, or predictive, project management in the context of information systems. The chapter delves into the significance of project management within the realm of information systems, highlighting its role in ensuring successful project outcomes. Key topics covered include project initiation, planning, execution, monitoring, and closure, with a specific emphasis on how these phases relate to the unique challenges and requirements of information systems projects. By providing a comprehensive overview, this chapter aims to equip readers with the fundamental knowledge necessary to navigate the complexities of managing projects in the dynamic field of information systems.
Discussion Questions
- What are some unique challenges in managing IS projects compared to other types of projects? Can you give specific examples?
- Why is it important for IS project managers to align projects with business objectives? Can you think of a scenario where a project was technically successful but failed to meet business objectives?
- How does the concept of the ‘Triple Constraint’ apply to IS project management? Can you give an example of a trade-off you might have to make between scope, time, and cost in an IS project?
- Why is stakeholder management important in IS projects? What strategies can be used to effectively manage stakeholders?
- Discuss the role of quality management in IS projects. How does it relate to the concepts of scope, time, and cost?
- How can the tools and techniques discussed in this chapter, such as the Work Breakdown Structure (WBS) and Gantt charts, help in managing IS projects? Can you think of a scenario where they would be particularly useful?
- What are some potential risks in IS projects, and how can they be managed? Can you think of a real-world example where risk management (or lack thereof) significantly impacted an IS project?
- How does change management play a role in IS project management? Can you think of a situation where poor change management led to project failure?
- Why is communication important in IS project management? What strategies and tools can be used to facilitate effective communication in IS projects?
