We start every custom software project with the define stage of our 4D Methodology. What exactly are we trying to accomplish during this stage? While it is true we are trying to define the project requirements, there's more at work here. We also want to define the criteria management (and the users) will apply to determine if the project is a successful one. And we also need to setup the mechanisms we will use to manage and track our progress. To put it succinctly, the define stage is the foundation of the project.
So exactly what are we doing in the define stage? Let's list the specific activities below:
Planning/Discovery
- Identify Project Goals and Objectives
- BU Key Contacts and Project Sponsor
- Create Vision Statement
- Conduct Preliminary Meetings to Determine Requirements
- Document Milestones and Deliverables
- Discuss Expectations and Assumptions
- Identify Project Risks
- Determine Constraints
- Identify Resources, Roles, Responsibilities
- Identify Steering/Operating Committees
- Develop Preliminary Effort and Timelines
- Create High Level Project Plan
- Establish Status Reporting
- Set Weekly Meeting Schedules
- Review Change Control Policy
- Discuss Reviews and Approvals
- Establish/Review Estimated Budget
- Clarify Communication Channels
- Determine Kickoff Meeting Date/Time
As you can see from the list above, there are quite a few things to do at the start of any project. One of the things that should be clear by now is that the define stage involves two major groups of activities. First, understanding what the high level scope of the project is. But more importantly, we want to define how we are going to control the project. You absolutely must have this step in stone to succeed, especially with complex enterprise solutions.
After we've established the high level requirements, and put in place our mechanisms to control the project, we need to analyze the project requirements in more detail. Let's review what is involved in this portion of the define stage:
Requirements Definition
- Business Requirements/Analysis
- Disaster Recovery Requirements
- Requirements List
- System Controls
- Benchmarks
- Data Requirements
- Key Process Definitions
- Process Flow Charts
Here are a few things to keep in mind while reviewing the above list. First, this is the meat and potatoes of the define stage. We will be conducting multiple meetings, including meeting with stakeholders, users, technical staff, etc. to get a full picture of your project. Some would say that this is where the fun begins.
Once we've captured all this information, we'll create a Conceptual System Design (CSD). What exactly goes into a CSD, and what is it used for? First, let's list the major parts below:
Conceptual System Design
- High Level ERD
- High Level Conceptual Diagram
- Conceptual Design Narrative
A Conceptual System Design is a very high level diagram and narrative which identifies the major parts of the system, along with the interactions they have with each other. In other words, based on our analysis of your project, here is what we think it should do, conceptually.
Moving on, next we'll create a more detailed and accurate Project Plan. Let's look at what goes into it:
Project Plan
- Gantt Chart
- Work Breakdown Structure
- High Level Task List
You probably know what a typical project plan looks like, so I won't go into too much detail on this one. I would, however, like to point out that the high level project plan we created in the planning/discovery stage will differ significantly from this one. Of course, with more details, we now have a much better view of your project. Changes to the project plan are a natural occurrence at this stage.
Define Checkpoint / Sign Off for Next Stage
Once all the above steps are completed, we conduct a formal review (checkpoint) with stakeholders, project sponsors, end-users, management, etc. This is done to verify that the system we are about to design is the same system all members of your team desire to create. It is not uncommon to flush out minor changes during this presentation.
One more comment about reviews. It is usually desirable to have review sessions after each of the major portions of the define stage are completed. Each part builds on the last, so we want to catch ambiguities and incorrect assumptions as quickly as possible.
I hope you found this section informative. In the next section I'll review how we design software.