Planning for IT Projects

Why do we build a plan?

One of the first questions any client is bound to ask (besides "How much will this cost?") will be, "How long will it take?".  This can be a very ambiguous question until you have a better understanding of the scope of the project and your resources (i.e. budget, team) you have at your disposal. 

Time, which is the 3rd constraint of any project, can only be determined by putting together some sort of project plan that answers questions such as:

  • What tasks are needed to realize this project? (i.e. scope)
  • How long will each task take to complete? (i.e. time)
  • Who will be assigned to complete these tasks? (i.e. resources)
  • What order do these tasks need to be completed in? (i.e. dependencies)

The “Triple Constraint” of project management is the combination of scope, time, and resources.

Without making a plan, we can’t communicate milestones to end users, we can’t set a budget for the project, we can’t properly allocate resources (team assignments), and we can’t determine the feasibility of a project.  It’s a common misperception that Agile ignores initial planning and documentation but this is simply not true.  Plans are critical but also are not meant to be a perfect predictor of how our project will go.  Plans are meant to be “living” documents that are monitored and adjusted throughout the project.

What are the components of a plan?

Inception Phase

Whether you are using Waterfall or Agile or a mix of both, your project must start with some form of an Inception phase.  The goal of the Inception Phase is to gain a good understanding of your project scope, time, and resources (i.e. The Triple Constraint).  Even before the first meeting with your client, you can anticipate that we’ll need to perform lots of analysis using important frameworks that are designed to help us determine important project details like stakeholders, root cause, as-is process models, functional requirements, non-functional requirements, scope priorities, organizational impact assessment, project risks, evaluation table of system alternatives, etc. 

During the Inception Phase, we also analyze the hardware/software environments and begin the process of setting up our environments for development and production (if this is a brand-new system).  We also establish our development team roles and setup a preferred method of team communication.

Sprints

“Sprint” is a term that comes from the Scrum style of Agile software development.  In Agile software development projects, work is planned in regular, repeatable work cycles lasting 1-2 weeks and these are called sprints.  Within a sprint the goal is to start, develop, test, and deploy a single user story or even a collection of user stories.  The number of stories a team can complete depends on how many resources the development team has, and also on how much change the client is willing to take on after each sprint.  A typical agile project will begin a chain of sprints following the inception phase.

ADCRD Loops

In order to make each user story more tangible and actionable, we consider the four subcategories of tasks that we will be going through for each user story.  In 374, these subcategories are ADCR, which stands for Analysis, Design, Construction, and Review.  They are defined as follows:

  • Analysis is the group of tasks related to gathering additional information and iterative prototyping that the development team will need to complete in order to start the design portion of the user story.
  • Design of the user story includes tasks that involve identifying how we will construct the functional and non-functional requirements of the user story. We also design the initial outline of training materials and user documentation, and think about important test case scenarios we’ll need to cover when the system is built and ready for testing.
  • Construction of the user story includes tasks where we create or build out what we designed. This can include constructing functional requirements within the database, such as queries, forms, or reports, and also non-functional requirements, such as security, performance testing, or commenting code for maintainability purposes.  We do our initial construction in our development (“dev”) environment.  Once the initial construction is complete in dev, each developer will test each of his or her own components or requirements, which is called unit testing.  Construction also includes various “creation” tasks, like creating test data, creating test cases, or creating the user materials and training.
  • Review is the last part of the user story and includes tasks related to further testing at the macro level (e.g. Test that volunteer can enter a donation for an existing donor) rather than at a micro level (e.g. A pop up prompts you to save when you click Cancel button). Within the review portion of a user story, the users should get to do User Acceptance Testing (UAT), where they evaluate whether the user story was built as they expected and if so, sign off to approve the deployment.
  • Deployment - To “deploy” our code means that we migrate the new functionality from our development environment into production.  Assuming that the review part of the user story is completed with the client giving their approval for deployment, the deployment of that user story can move forward.  After the user story is deployed, the team can reflect on how the sprint went, document ways to improve, and then move on to the next sprint.

Keep in mind that deployment is hard, especially on your first sprint, which is why we aim to deploy working software multiple times in the project.  With each iteration, we learn about and improve our ability to deploy.  We also gain the advantage of experience, meaning that we know better what to test, the steps to deploy, and how to communicate with users when deploying.  The expectation is that Deployment 4 will run much smoother and Deployment 1, not only for your development team, but your users, too.