Project Planning

Introduction

Project Planning and Management encompasses all aspects of managing a project, including planning, identifying requirements, determining priorities, assigning and tracking tasks, coding, testing, maintenance, and deployment.

Following the SDLC

In essence, project management is the execution of the (SDLC) Software Development Life Cycle. It is not conceptual, but the concrete planning, execution and tracking of the stages and tasks required to complete the project.

For the project team, the main concerns are

  • What needs to be done? (requirements)
  • How does it need to be done? (standards)
  • When needs to be completed and in what order? (tasking)
  • Who will do it? (task assignments)?
  • How do we know what is ready, complete, needs reworked, etc.? (task tracking)
  • How do we know what is complete and ready to be deployed? (testing)

Every stage of the process (Plan, Design, Build...) involve many of the same issues (what, how, when, who). For this chapter, we will assume the project at hand is a database project, and that the requirements for the database design are mostly complete. We'll concentrate on planning and managing the tasks to complete the rest of the work.

Planning: What to Do

Planning encompasses everything else. Even if the requirements for the application have already been determined, what are the requirements for completing all of the design, coding and testing? The project manager (or the team) must determine

  • the tasks to work on
  • what specifically needs to be done
  • the order or priorities of what needs to be done first, second, etc.
  • How should things be done? Are there standards to follow?
  • How should things be tested?
  • How (and who) will keep track of all of this? Where do things stand?
  • How are complete pieces deployed?
  • How does all this need to be reported?

It may be possible with small projects to use tools such as Word and/or Excel to prepare and track all of the planning items. Larger projects require more complicated software such as Microsoft Project or online tools such as Wrike, Smartsheet, Trello and GetFlow.

Requirements: What Specifically Needs to be Done

Having the project requirements done and in hand does not necessarily explain all that needs to be done from a design and coding perspective. The project "Design" requirements may specify the need for a Customers table, possibly with an ERD detailing the table elements. Are the tables to be created from the application software ("Code-First Approach") or the database side ("Database First" approach)? Is test data required? Should tables be created and populated in a specific order? What standards are being used for doing this work?

The order in which tables are created may be important. If tables have foreign keys and foreign keys constraints, creating the table may fail if the referenced table does not yet exist. Likewise, attempting to populate a table with test records will fail if the data required by a foreign key constraint does not exist.

The same is true for creating other database objects, such as views,, stored procedures, triggers, functions, etc. So, it is best to plan the order in which such tasks need to be accomplished, especially if the work is being performed by multiple people on the team.

Order and Priorities

Should tables and other database objects be created and populated in a specific order? What is important to do first, second, etc.? What tasks rely on other tasks to be complete?

The order in which tables are created may be important. If tables have foreign keys and foreign keys constraints, creating the table may fail if the referenced table does not yet exist. Likewise, attempting to populate a table with test records will fail if the data required by a foreign key constraint does not exist.

The same is true for creating other database objects, such as views, stored procedures, triggers, functions, etc. It is best to plan the order in which such tasks need to be accomplished, especially if the work is being performed by multiple people on the team.

In advanced project management software, such as Microsoft Project, tasking sequence can be defined and displayed using a Gantt chart. For a simple case, a bulleted outline may suffice to define both sequence and sub-tasks (how tasks are related).

How Things Should Be Done

The project requirements may or may not get down to the level of detail of how work should be done at the design and coding level. For instance, do all number columns have a default value if not required? Should table columns be named using camel-casing or something else? Are abbreviated names allowed? Do identity columns use a specific seed value?

All projects should include and use standards for design, code organization, coding, documentation and testing. That is not always the case, and it may be up to the team to create and document those standards. Without standards, the resulting development may end up with a hodge-podge of code and objects (even if a single developer does it all!).

At a minimum, database projects benefit from the following standards:

  • Naming guidelines: tables, columns, stored procedures and other objects; use on abbreviations
  • Guidance on defining data types and keys
  • Assigning contraints, including defaults, NULL and NOT NULL, check and unique constraints
  • Rules for referential integrity, including foreign key constraints and cascading actions
  • Parameter and variable naming within procedures and other code
  • Exception and transaction handling; exception reporting/logging

Testing: Is it Ready?

Smaller projects sometimes forget to have a Test Plan. A test plan explains how each part of the application should be tested.

The team needs to know and understand how things should be tested, what results are expected (good and bad), what signifies the code is "done", and how to report testing results.

Many projects create test scripts that describe the exact steps that should be taken to perform a test, and what the results should be. In addition to confirming a good result, there should also be test scripts that attempt too cause errors.

For example, if a web form is intended to insert a customer record in the database, the test script might specify

New Customer Record Entry

  1. Navigate to the Customer Input Form
  2. Enter new customer name
  3. Enter state code
  4. Enter zip code
  5. Click Save button
  6. The screen should report that "New customer record was saved."
  7. [Record a successful test, if no errors]

New Customer Record Entry: Invalid Data Entry

  1. Navigate to the Customer Input Form
  2. Enter new customer name (leave blankenter more than
  3. Enter state code
  4. Enter zip code
  5. Click Save button
  6. The screen should report that "New customer record was saved."

New Customer Record Entry: Invalid Data Entry 1

  1. Navigate to the Customer Input Form
  2. Leave all fields blank
  3. Click Save button
  4. The screen should display error panel with appropriate errors for required fields

New Customer Record Entry: Invalid Data Entry

  1. Navigate to the Customer Input Form
  2. Enter new customer name (attempt enter more than 40 characters)
  3. Enter state code (attempt to enter XX or other invalid state code)
  4. Enter zip code (attempt to enter more than 10 characters)
  5. Click Save button
  6. The screen should report that "Invalid entries must be corrected."

As suggested above, it is important intentionally test for bad results and errors. And this often means many more tests that just testing to see if it works correctly.

Tasking Assignments

Who does what is up to the project manager, or perhaps an agreement between team members. This should be documented, so everyone knows the assignments. That way, if the code that one member is working on is dependent on another piece being complete and working correctly, team members know who to work with to resolve issues.

This also assists collaboration. If a team member needs to start work on a stored procedure, it might help to collaborate with the team member responsible for the tables that will be referenced in the code.

Tracking Progress

Every project benefits from knowing where things stand. What is done? What needs to be completed next? Who is responsible for these tasks? If there are problems or changes, what are they are who should address them?

However, even for small projects, this can be a daunting endeavor. Online tasking software assists this process because team members can indicate that they are starting a new task or have completed a task. Tasks can also include a status (Started, In Progress, Ready for Testing...) and comments describing issues,, etc.

For smaller projects that are attempting to track things in Word or Excel, for example, it may be harder to track details at a lower level. For example, it might be enough to track "Ready For Testing", and a something like "Passed/Failed"

Conclusions

Project planning can be a daunting task. The larger the project, the more parts, issues and people there may be to track. Knowing where the project stands at any point in time is a key objective. Knowing what needs to be done next, what issues need to be resolved, and what has not yet been tested, are all key indicators of the project status at any point.