A number of methods evolved in managing a Software Project during the past decade. Whether it is a Traditional or Agile Development, the emphasis on the phases of the Software Development Life Cycle remain unchanged. While the earlier Project Managers are inclined more to the principles of Managing the Projects, their competencies in the technology that is being used in the Project are least bothered. The rapid change in Technology and the Internet Boom made the newer generation of Project Managers to be competent technically and experienced in Principles of Project Management(2) . Globalization and Outsourcing of IT Projects demanded additional skills for managing these Projects.
In this challenging IT World, creating a project plan with cost-savings techniques and better metrics for quality assurance became an ever-demanding task for the current Project Managers.
When the Software Project Manager is well-versed in the business process and experienced in Software Development/Analysis, then this author believes that the below explained “Functionality-Based SDLC” will be more successful when compared to the traditional SDLC.
Major Functions Identification:For any application, the best way to identify the functions involved is to discuss more with the Business Community. The End-Users are the best resources for gathering the requirements and identifying the tasks and grouping them into functions. In most of the Software Projects, it’s the Project Manager who decides how to plan the Project and get it executed. Theoretically, it works if the Project Manager had any previous experience as a Business Analyst or a Systems Analyst.
Since most of the Projects are not started from scratch, there is always the business process flow for most of the functionalities and their inter-dependencies already in place. The primary task is to gather all the functionalities required to be developed or enhanced based on the Project Scope. Organizing these functionalities at a higher level for presenting to the Business Community and Senior Management will provide a better commitment to the Project Manager. This Presentation would be the first step for the Business Sponsors and the Project Manager to come to an agreement that all the functionalities are within the Scope defined. Any miscommunication or misleading information MUST be clarified at this stage. Most of the failed Software Projects are due to lack of clarity in the Project Scope.
Digging through more in detail for each functionality with the Business Community and in particular with the responsible End-Users provides a better understanding of how the Project should be planned. During this Phase, the author expects the Project Manager to be well-versed technically about the in-and-out of the Business Process. A Technical Leader might be a catalyst during this Phase.
Once the detailed functionalities are identified, they can be further organized as Independent and Dependable Functionalities. Breaking down the functionalities to the lowest level possible at this phase will be more helpful while planning for the Work Allocation, Identifying the Team Size, Identifying the technical skills required.
Project Planning:The Functional Process Flow used the Arrow Diagramming Method. The Forward Arrows indicate that the Next Functionality that need to be started once the existing one is finished.
For each Functionality, the SDLC phase consists of:
Fn Rn – Requirements Gathering (Where nis the Functionality Number)
Fn Tn – Test Cases Preparation
Fn Dn – Detail Design Documentation
Fn Cn – Source Code Development
Fn Un – Unit Testing
Planning for each functionality relies on the time taken to gather the requirements. Gathering all requirements for Independent Functionalities should be the first priority. While the Team is busy in progressing other phases of Software development for these Independent Functions, the Project Leader/Manager will have sufficient time to gather the requirements for functions that are depend on each other. Once again, I would like to emphasize that a Software Project Manager with experience in Programming would be an added advantage during this crucial phase.
In the below diagram, after the completion of gathering Requirements for Functionality 1 is completed, the other tasks pertaining to that Functionality can be started. While the Team is working on these Tasks, the Requirements for the Next Functionality can begin. During this planning phase, the Project Manager would be able to identify the Team Work Load and any possible delays. All adjustments to workload breakdown between the Team Members must be finalized during this Phase. To avoid panic due to any unexpected risks (viz. Team Member leaving in the middle of the Project or delay in Software Licensing or delay of acquiring the required Hardware etc..) it is advisable to add at least 15% to 20% of the planned time. Any extra time during any phase will be an added advantage for the Team to work for the next phase with less stress.
Critical Functionality Path (CFP) Evaluation: It can be defined as the Path from Start to End where more interdependent functionalities are involved.
Any change in plan for any one of the functionality would have a major impact on the next dependent Functionality. To avoid any such mishaps, extra time must be included for each inter-related functions during the planning phase.
A Hypothetical Case Study – “Retail Pharmacy Medicines Dispensing System (RPMDS)
“In this hypothetical case study the project manager is assumed to have experience in Software Development in HealthCare Industry. The Project Manger identified the individual and interdependent Tasks. Based on the number of Software Professionals assigned to the Project, the Project is planned.
For this Application, various functionalities are identified as follows:
– IT1 – New Prescription Input
– IT2 – Refill Prescription Input
– IT3 – Fill the Medicine (Assumption is Made that HMO/PPO authorized )
– DT1 – Gather Prescription Information – Depends on task IT2
– DT2 – Authorization from HMO/PPO – Depends on task IT1 and/or DT1
– DT3 – Print the Co-pay Amount – Depends on DT2
– DT4 – Bill the Insurance – Depends on DT2
Critical Functionality: DT2 – Authorization from HMO/PPO
In this Arrow Diagram, Function 4 can be started as soon as Function 1 is completed. By planning intelligently, by the tine Function 3 gets done, Function 4 must be in its final finishing phase.
Since Function 5 is independent, it can be started with an assumption that the HMO/PPO authorized to fill the Medicines as per prescribed.
After completion of Function 4, Function 6 and 7 can be started in parallel.
In this Case, the CFP is: F2 — F3 — F4 — F7
At this point, the Project Manager can plan in two ways:
Plan 1: Divide the Project Team into exactly two groups and assign one group the Individual and the other the Interdependency Tasks.
Plan 2: Assign each task to each member of the team as mentioned in the Arrow Diagramming Method.
What ever the Plan the Project Manager chooses, there is always a risk associated with it. The best way to minimize the risk comes from the past experience.
This paper has dealt more in detail how to plan a project if the functionalities are clear and their inter-relationships are identifiable. For large scale projects the functionalities can be identified at a higher level and for each functionality the same process can be repeated. The deeper the functionalities are broken-down for simplicity purposes the higher chances of getting them completed with minimum risk. Be cautious, too deep might let you fall in an endless dark tunnel. As emphasized earlier, a technically competent & experienced Project Manager can decide the depth.