What Is IT Project Planning?
Information technology project planning, or IT project planning, is the effort a team makes at the beginning of a project to ensure that work proceeds well. These steps also help ensure the project meets its deadline and overall goals.
Planning is the second phase of an IT project, after project initiation and before project execution. Learn more about the initiation and execution phases and IT project management. To learn about prioritizing these projects, visit our comprehensive IT project prioritization guide.
How to Plan an IT Project
Planning an IT project requires taking key early steps. These include helping team members and stakeholders understand the overall objective of the project. Plus, clarifying how the team will define and monitor the work.
IT Project Planning Steps
Experts recommend a number of steps to effectively plan for an IT project. Start with convening a kickoff meeting of project team members and stakeholders to discuss the broad outlines and objectives for the project.
Here are 13 important steps in planning an IT project:
Step 1: Convene a Kickoff Meeting
A kickoff meeting is vital. It’s an opportunity to get team members, clients, and other important stakeholders together to discuss objectives for the project and set expectations. Meeting participants may also discuss possible risks.
“What we tend to do in this meeting is ask all stakeholders to be present,” says Shai Shandil, Founder of softsolutions consulting, which provides consulting and training services to help companies with technology projects.
Shandil says that in past years, he would recommend people come to the meeting even if they had to fly to get there. These days, that requirement is probably relaxed. But everyone should attend either in person or via video because the meeting is vital for bringing everyone to a common understanding of the project and its goals. “We’re trying to get to a place where we have a standard understanding of what's deliverable,” Shandil says.
To learn more about planning a kickoff meeting, read our comprehensive guide to project kickoffs and download free project kickoff templates.
Step 2: Ensure You Have Leadership Buy-In and Engagement
Company leadership must show it is invested in the project and considers the work important. Leaders also must be engaged in the project. They should attend update sessions and provide their input.
Leadership buy-in “is the mini step,” Shandil says. “I talk about deep engagement of leadership, and it has to be comparable to the budget they’re willing to put in. If they’re putting in five bucks, then sure — if I make a mistake here, it’s OK. But if they’re putting in millions and it’s 80 percent of the total budget, then you're starting to think, ‘I can't have you come in once a quarter or once a month, and look at some reports. That's not enough. I need you to be in there with us to give guidance because you bring the vision.’”
Shandil says that doesn’t mean leadership is in every Scrum meeting or other project meeting. “But what we do want is for them to turn up every two weeks and look at the things that we're pushing out,” he says. “Whatever the cadence — if it’s two weeks, four weeks, or three weeks — the idea is: ‘Come and touch base with us and look at the product.’ They actually look at it — not some proxy to the product, not a PowerPoint deck, but the actual product. We need you to then be able to go to the board, the customer, or the market and say, ‘Hey, this is what we're doing.’”
Step 3: Create a Project Charter that Includes Objectives
Creating a project charter before starting work on a project is essential. The charter provides details on scope, resources, and timelines. Possibly most important, it sets out the project’s primary objectives. Make sure you and your team are certain that those assumed objectives are the right objectives.
“One of the most critical aspects of planning an IT project is clearly understanding the objectives of the project,” says Alan Zucker, Founding Principal of Project Management Essentials, who has more than two decades of experience managing projects in Fortune 100 companies. “Objectives are the ‘what do we want’ and ‘why do we want it.’ Scope is the ‘how are we going to deliver it.’ Understanding objectives is important because there may be multiple solutions to solving the problem and we want to understand the problem before deciding how to solve it.
“Start with the why.’ Start with the objective. Ask questions. What will meeting that objective allow us to do? What do we hope to achieve?”
Step 4: Establish Proof of Principle
An important part of understanding and setting objectives is to fully understand the product your IT project is set to develop. You must be certain the product is technically possible and worthwhile.
“Make sure there is clarity around what you want to deliver,” says Zucker. “A proof of principle — that’s going to be invaluable.”
“Do a proof of concept [for the product],” says Patrick Sim, Co-founder of RobustTechHouse, which develops IT projects for clients, and FacilityBot, which uses technology to help manage facilities and manufacturing plants. “And do it first. If you can’t make it, then forget it.”
If you can’t technically make the product, or you’ll have trouble selling it for the price you need to cover costs, then you need to know that at the beginning, Sim explains. And you may need to end the project. “Move on to something else,” he says.
Step 5: Establish a Budget (But Understand It May Need to Change)
You’ll want to establish a broad budget for the project. But create a structure and processes that allow the budget to change when necessary. That’s particularly important for IT projects because products often evolve as they develop.
Experts also point out that a key feature of IT projects (and products) is the budget increases as the project succeeds.
“One key issue is that successful IT projects are well utilized and often require ongoing new features and improvements,” Sim says. “Additional costs will continue to be incurred — particularly for successful IT projects. Every successful product you see out there … they're always adding features, right? Therefore, the budget has to increase. This is part of the buy-in that management has to understand.”
Step 6: Establish Project Scope
Once you set your objective and the tentative budget, it’s time to establish the exact scope of the project. You will set the parameters of what the project will produce or complete and what it won’t do.
“Once we have an understanding of what is wanted and why, we can begin to ask questions about scope,” shares Zucker. “We can start looking at high-level project scope. What’s in scope? And, often as important, what is out of scope?”
You can download a template to help you detail the scope for an IT project.
Step 7: Create a Project Management Plan
Once you determine the objectives, budget, and scope, you can complete a project management plan. This plan provides an overall structure for how to accomplish the work.
“The project management plan should be customized or tailored to the specific project,” says Zucker. “It is the project manager’s guide for executing the project.”
View and download free project management templates to help you create a project management plan.
Step 8: Articulate Team Member Responsibilities from the Start
The project management plan will include basic information on who is responsible for which tasks and deadlines. It’s vital that each team member understands, at the onset, the tasks for which they are responsible.
Step 9: Decide on the Best Methodology for Your Project
Early in the planning process, you’ll want to decide which project management methodology to use. That likely will be Agile or a modified version of it. Some IT projects still use more traditional methods.
Zucker advises asking “what kind of project are we executing and what type of methodology is going to fit well with this project.” For many IT projects, that means Agile or some version of it, which allows for the continual changes and adaptations that are part of an IT project.
Zucker adds that “the decision on whether this project is going to be Agile or traditional may be made for you” because many organizations have a preference for the methodology they use to manage projects.
For a small minority of IT projects, traditional project management — including the Waterfall methodology — might be best, Shandil shares. “Those tend to be the verticals that have less change and are highly regulated,” he explains. “Banking is an example of that. I worked with a company that was basically selling companies online. With stock market regulations ... all those things barely ever change. For them, they were a niche and doing incredibly well. And we said, ‘You guys should just keep doing Waterfall; it works really well.’”
Step 10: Plan to Hold Recurring Regular Strategic Meetings
You need to conduct regular check-in meetings with everyone in the project, including clients and stakeholders. Experts recommend holding those meetings at least once per quarter, or as frequently as monthly for smaller teams.
Step 11: Establish Product Specifications
First, set your objectives and ensure that the product your project is working on is viable. Then, list the specifications for your product in significant detail.
“The most important thing is the specifications,” says Sim, from RobustTechHouse. “What is the project? What is going to be produced? You'll be surprised that many clients — I would say 60-70 percent — don’t actually have that.”
Clients who might be less technology savvy or have less technology experience often set specifications at an extremely high and general level. They need to be more specific on what the product will do, how it will do it, and the metrics on how it will do it, Sim states. “Without a detailed requirements document, budgeting — for both time and cost — becomes very difficult,” he says.
Meanwhile, larger organizations have a different problem: many people with different opinions on the product and what it should do. “Sometimes, the big organizations have all this bureaucracy, and many people have different opinions on what should be done,” Sim adds. “They cannot reach any sort of consensus on ‘OK, this is the product that we want to build.’ So (it’s important) to actually get to the stage of good specifications.”
Step 12: Understand and Address Technical and Other Risks
The project team needs to quickly understand the highest risks to the project’s (or product’s) success. Those may be technical or other kinds of risks. The team will want to understand and address them to avoid failure.
Technical risks — the technology won’t work correctly because of technical limitations or problems — are especially important in IT projects. Experts suggest teams identify and work on those possible risks early to avoid wasting money on a project that is destined to have problems.
“Spot the technical risks early and test whether (the product) can be achieved,” Sim suggests. “Additional staff can be added along the way. More important is to identify the key technical risks — any particular area in which the tech team has not much experience — and build that component first.”
Shandil agrees. “You take the riskiest thing that's the most important to the customer and do it first,” he explains. “Let's say we’re building an accounting system. Part of the risk is holding a customer’s sensitive data. Then we would build that part of the accounting system first, push it out, and make sure it works. You've managed the risk by bringing it often and early and making sure that all those assumptions you made around privacy laws, etc., across the whole organization or country — those are getting dealt with early. You don't get to the end of a project and have unknown, non-tangible problems.”
Step 13: Get User Feedback Early and Often
When your team is building a new IT product, it is crucial to check on how it’s working (or not) as early as possible. That means getting user feedback as you build the product.
Experts recommend creating the minimum viable product. That means getting the new product into the hands of users as quickly as possible, even when only one or two basic features are working. With their feedback on that early version, the users will then help you develop the product further.
“Go to market early and get real user feedback,” Sim adds. “Too many projects get stuck in budgeting and feature-over-engineering hell and never start.”
Shandil says many companies will pay prospective users to try out the new product in order to get their reactions. With a new accounting system, for example, “your strategy might be to talk to accountants and say: ‘Look, we’re pushing this product out. Could you come and have a player run — paying $20 an hour or whatever — just to have a play and give me your specific thoughts on how this would work in a cloud environment?’ We call it user interviews. But basically, it’s a feedback loop that allows you to mitigate risk quickly, cheaply, and easily.”
Traditional Project Management Components That Are Different in Agile for IT Projects
Planning for more traditional project management, such as using Waterfall methodology, includes a number of steps and documents. These efforts are less common or applied differently when IT projects use the Agile methodology.
For example, teams often use a work breakdown structure (WBS) in traditional project management. The detailed diagram shows all tasks that a team needs to check off to complete a project. Learn more about how to get started with a work breakdown structure.
Agile projects don’t use work breakdown structures. But an Agile product backlog or product roadmap often serves similar purposes.
Traditional project management also may include steps and documents to:
- Adopt risk management planning
- Handle communications planning for team members, clients, and stakeholders
- Implement change management planning
- Perform budget planning
- Plan for needed resources and staffing
- Schedule all project activities
When teams use Agile to plan and execute their IT projects, they take many of the same steps as above, though differently and often less formally. Instead, these steps are sometimes part of sprints and iterations.
Here are more details on understanding how Agile works — and whether your team is appropriately using Agile or is just saying it’s using Agile.
IT Project Plan Example
Download IT Agile Project Plan Example — Microsoft Excel
This example Agile project plan template comes already completed to help you understand how to plan your IT project. The example template includes entries for specific Agile sprints, along with features within those sprints. You’ll also find sections for team members who are responsible for each item, planned start and finish dates, and current status.
Agile Project Plan Template
Download Agile Project Plan Template — Microsoft Excel
You can customize this Agile project plan template to plan and monitor your Agile IT project for your own purposes. The template includes sections where you can add tasks, responsibilities for the tasks, start and end dates, and status. The duration for each task will be automatically calculated. This template also features a Gantt chart (a visual representation of your project timeline), which will automatically adjust when you add your own data to the table.
How Planning Is Different for IT Project vs. Non-IT Projects
IT projects are notable for how much adjustment and change happens from the beginning of the project to the end. Many non-IT projects have much less change. Thus, planning for many IT projects requires different approaches.
Here are two primary differences:
- IT Projects Are Much Less Likely to Use Traditional Project Management Methods: Traditional project methods such as Waterfall are solid options for some construction projects. Significant changes in plans are less likely in such projects. But software development and other information technology projects encounter significant changes throughout, making them more likely to use Agile or modified Agile methodologies.
- Budgets Are More Likely to Change: Budgets in IT projects can change when unforeseen hurdles or problems require adjustments. But budgets can also change with project success. That can happen when a new IT product (developed over the course of a project) becomes successful and loved by customers.
“A difference between non-IT and IT is when you finish an IT project it's actually the start of something,” Shandil says. “When you finish any other project, it's the end of something.”
When construction crews finish a building, the construction budget is also done. But when software developers finish software and customers love it, those customers continually suggest changes to improve it. That means the budget for successful software and IT grows when it’s successful.
“If you spent $2 million on software, you're going to spend $8 million before you retire or sunset it,” Shandil explains.
Tips for IT Project Planning
Experts recommend forming and maintaining project teams. You should also determine planning documents that are necessary and those that aren’t, as well as how to show work and progress.
Here are some top expert tips for IT project planning:
- Maintain Ongoing Project Teams: Some organizations may create a custom team for each specific project. But Zucker says there are advantages to maintaining ongoing teams of mostly the same members — called persistent teams — working on project after project. Team members get to know each other and what everyone does best, making project work move more efficiently.
“Persistent teams can be used in either environment: Agile or traditional,” Zucker says. - Ensure Your Goal Is the Right Goal: Too often, company or project leaders announce a goal for a project and immediately begin planning to achieve it. But they don’t always analyze whether that goal is the right goal or if accomplishing it will achieve what they want for the organization.
“I’ve seen that whole thing played out a lot of times,” Zucker shares. “They spend 15 seconds on what I want to achieve, then immediately drill down into details on how to implement the thing. Let’s make sure that’s what we want to do.” - Make Sure You Define Final Success in the Right Way: Success in IT projects isn’t about the number of features you’ve added to a piece of software or a digital system, Shandil advises. It’s about customer happiness.
“The best outcome is happy customers, so we would usually be thinking: How many features have you pushed out this month? Instead, we should be thinking: How many happy customers? Did we make them happy with those features that we pushed out this month?” he suggests asking. - Don’t Focus Too Much on Detailed Written Documents: Agile methodology is less focused on requiring formal written documents than more traditional methodologies. But even in Agile, some documentation on the basic project management plan and scope is important. What you don’t want, however, is to waste time writing documentation that immediately becomes obsolete and inhibits project progress.
“The trade-off is that it makes you less nimble, because it takes time to write these things. A lot of times you're projecting into the future. You may not even know exactly what your product is. Decide on what documentation is really necessary and then edit. This is also a skill — deciding what is absolutely necessary and what is not necessary,” Sims advises. - Don’t Focus Too Much on Upfront Planning: This tip is related to limited documentation. Don’t spend too much time doing detailed planning before your work starts. You’ll want to set some basic objectives and structure, of course. But then get to work.
“Plan now to plan later,” Shandil says. “And in the meantime, learn a bit more.”
That means your team can work on the product or project for a limited time — during a week-long sprint in Agile, for example. “Team members will learn more during that week of work, then they might make quick plans for the next week of work. And you just iterate on that,” Shandil says. “The key difference for us is you have to deliver something, because otherwise you're not learning anything.” - Understand and Use the Concept of Minimal Viable Product: A minimum viable product is a concept that encourages developers to get a basic version of a new product into the hands of users as quickly as possible. That means it’s not the finished product, but it works at a basic level and can give a user an idea of the concept. That early user feedback can then help you add other features and further develop the product.
“The best feedback is from actual users,” Sim states. - Establish a Working Agreement on Work Culture: At the start of a project, Shandil encourages clients to agree on a working agreement, which sets out basic rules and principles around how people will work together.
“This is really getting people to act more like a team and less like a bunch of individual contributors,” he says. “So we actually came up with a rulebook for the team.”
Rules might include, for example, silence is agreement. “That way, people understand they should contribute to discussions, and if they don’t, they can’t say later that they didn’t agree,” explains Shandil.
- Make Sure Everyone Can Easily See, Monitor, and Track Progress on a Project: Every team member, client, or stakeholder should be able to easily see a project’s status and progress. Team members can see how much work remains and people external to the project understand the work that is happening. That can help build political, financial, and other support for this project, and future ones.
Shandil remembers an instance of working at an Australian healthcare organization that was bought out. The CEO of the purchasing company visited the offices and saw a large whiteboard with projects written on it in the IT department.
“She looks at this board and says, ‘Wow, you guys do a lot of work. I don't think my guys down in Sydney do this much work.’ We knew that was not true. It's just that they didn't make it visible. That idea is really key for us, because she could walk past the knowledge workers and a bunch of stuff is happening in our heads. She has no idea, right? Bringing that to the table and getting people who don't necessarily have a technical background to actually buy into that process — that’s huge.” - Think About How You’ll Address Cybersecurity: Cybersecurity is important for all IT projects. For some IT projects, it may be the most important component to consider early in the process.
That means cybersecurity should be among the early risks that a team evaluates and plans for. Sim says he’s seen projects where team leaders assessed what it would take to ensure the necessary cybersecurity for the product. And that cybersecurity budget ended up being five times the assumed budget for the entire project.
“You know, that (project) doesn’t make sense anymore, right?” he says. “It’s better to find that out very early in the work, as opposed to later.”
The Failure Rate for IT Projects
The failure rate for IT projects is fairly high. Since 1994, the Standish Group has issued its CHAOS reports on IT project success. In its 2015 report, it found that 36 percent of IT projects were successfully completed in 2015. Another 46 percent were “challenged,” meaning the project was completed and operational but was over budget, completed past the deadline, or offered fewer features than originally planned. Another 19 percent of projects failed completely and were cancelled.
The Project Management Institute’s “Pulse of the Profession” 2021 report found some improvement in IT project success from previous years. Still, the numbers showed plenty of room for more improvement. The report found that 64 percent of IT projects were completed within budget and 59 percent were completed on time. The report found that 33 percent of IT projects failed and lost their budget.
Why IT Projects Fail
Experts say IT projects fail for many reasons. Reasons include unclear objectives, poor communication among project team leaders and stakeholders, and insufficient user feedback early in the process.
Here are details on specific issues causing problems:
- Project Leaders and Team Members Out of Sync with Each Other and with Stakeholders: In failing projects, project leaders and team members don’t communicate often enough with clients and stakeholders. When they communicate, they do so poorly, and each side has a different idea of project goals and objectives.
- Confused Accountability: Team leaders and team members can also be confused about who is responsible for what tasks and overall roles in the project.
- Unclear Requirements: A major factor in failed IT projects is the lack of clarity around product requirements at the center of the project when you begin.
- Too Much Segmenting of Work and Bad Handoffs: Good project teams include members from various company departments who can work together and make sure they and their larger teams don’t work in silos. Those silos can cause big issues involving tasks when moving a project between departments.
“The old way of doing it is almost like the Cold War dead drop,” says Shandil. “Someone goes to a park bench, puts something under it, and then walks away. Then someone comes and picks it up. We know that doesn't work.”
Team members from different departments need to work together in cross-functional teams, Shandil advises. “That idea of having a dedicated cross-functional team means no handoffs.” - Taking Too Long to Perform Preliminary Planning and Work on Product: Companies often take too long to plan and perform preliminary work on the product at its center. They should conduct some preliminary planning and work but get a version of the product into the hands of users as soon as possible.
The long planning and development come with another danger: the market will have surpassed the product they were planning to build. “If you take one year to launch anything, that's in itself too long,” Sim states. “And technology might surpass whatever you're trying to do.”
Streamline IT Project Planning with Smartsheet
Empower your people to go above and beyond with a flexible platform designed to match the needs of your team — and adapt as those needs change. The Smartsheet platform makes it easy to plan, capture, manage, and report on work from anywhere, helping your team be more effective and get more done. Report on key metrics and get real-time visibility into work as it happens with roll-up reports, dashboards, and automated workflows built to keep your team connected and informed. When teams have clarity into the work getting done, there’s no telling how much more they can accomplish in the same amount of time. Try Smartsheet for free, today.