A project is a temporary establishment, intended for the creation of unique products and services. “Temporary”, implies that every project has a beginning, and inevitably an ending point, reached when the established objectives are completed. “Unique”, on the other hand, means that the created products or services sufficiently differ from other similar products and services. The aforementioned two terms were one of many aspects acknowledged by our team while preparing the software project management assignment. The comprehension of the module outcomes during the assignment came in different stages and phases, implementing step by step the materials learned during the course as well as from external sources. In that regard, the present essay serves as a description of the process of working on the project, reflecting the issues that arose during the assignment.
The Process
The initial stage of the project was the deciding one, during which the directions of the project were established. At this stage, we took the user stories provided by the customer as the basis for setting the requirements, and accordingly established what we need to do. It should be noted that with the main outcome of planning at this stage is bidding, the project management involved only the initial start-up stage. In that regard the output of this stage was considered as our objectives, which are:
- Preparing the project initiation document
- Breaking down the project
- Configuring the management.
- Assessing the risks.
- Estimating the costs.
Each of the aforementioned can be further divided into several other steps, but nevertheless, these steps were considered as the primary ones, and at the same time partially corresponding to the typical output of the start-up phase. Accordingly, breaking down the task was one of the main objectives of this stage. Additionally, it should be stated that as the extreme programming model was chosen by the customer as the life cycling model, it was agreed that the functionality stated by the customer it will be the one delivered. In that regard, such processes as constant code improvement will be included in the processes as well as the risk associated with it.
Project Plan and Objectives
Planning involved the following steps:
- Define the objectives and the requirements (Jalote, 2002)
- Identifying a standard process for execution
- Defining a process for managing process
- Estimating the efforts
- Planning human resources and team organization
The output of the aforementioned project plan and objectives will be used in the preparation of the project initiation document and breaking down the project. In that regard, the first issue that presented a difficulty, and can be considered specific to the software project management is the absence of certain criteria to establish some of the elements of the project initiation document. One example of such elements is the business objectives. Business objectives are what justify the business case for the project. In that regard, such estimation is rather based on intangible elements, rather than tangible, e.g. gaining reputation and experience, increasing the company’s portfolio of projects, etc.
The project’s objectives were easier to deliver, considering that the customer’s user stories were the basis on which the team stood in their composition. Thus, the project’s objectives were identified as follows, in no particular order:
- Designing a web page
- Adding multimedia functionality to the webpage, i.e. media player.
- Integrating an electronic storefront into the website
- Designing a system of authorization with different privileges
- Create a database
- Attach the webpage to the database
- Testing and verification
- Hosting
It can be seen that all of the aforementioned objectives are deliverable, and thus, might represent concrete statements describing what the project tries to achieve. Departing from these objectives, high-level statements could be made, providing overall context for what the project is trying to achieve, aligned to the business goals (Mochal, 2010). As stated earlier, at this stage the business goals are hard to identify, as well as the overall context that the present project is trying to accomplish. The difficulty in doing can be explained and generalized, as it is related specifically to the area of software development and software project management. Despite the fact that the present project is a case study, the team made assumptions that the company we are working on is a new company.
Thus, in order to identify the context, it will require more than one goal to achieve high-level statements. Accordingly, business goals are hard to establish due to the fact that there are no comparison criteria, in terms of what this project will bring to the company. In that regard, it can be stated that the most favorable scenario is the one in which the new project is similar to the one already developed in the company. In such a case the possibility of successful implementation is higher. For software project development the case is different, due to that “[m]ost large software systems are one-off, with experience gained in one project being of little help in another” (MikeWooldridge). Nevertheless, the team managed to establish high-level goals, guided by the principle of comparison, the company prior to starting this project and afterwar. Thus, the high-level statements were outlined as follows:
- Initiate and develop the customer-orientation approach in the company, through increasing the customers’ satisfaction.
- Releasing a quality product that will gain the company recognition.
- Improving the financial situation of the company
- Gaining experience and increasing the portfolio of the company with large-scale projects
It should be stated that as an external company doing the work for a customer, our high-level statements are different from these of the customer, and are not connected to his/her internal business processes. At the same time, the outlined high-level statements can be linked to the objectives that our team established.
WBS
The selection of Work Breakdown Structure as a tool to decompose the work was based on the that the project implied intangible objectives. In that regard, according to extreme programming, one of the first steps preceding planning is the provision of the features by the customer, through user stories. Accordingly, these features do not resemble tangible objects, rather than actions that users will be able to do. Thus, the team was focusing more on what should be done, rather than what to do at this stage. Additionally, it should be stated that WBS is more suitable for software development, rather than PBS. As a personal example discussed in the group, the testing process can be assessed and its cost estimated as a process, rather than a product. One critical point was in estimating the number of activities involved in the WBS diagram. The intention was not to overload the graph with redundant activities, while at the same time not missing an important one. The latter might lead to that the risk analysis, the cost estimation, and the delivery time might be affected.
The decomposition of the work structure is one of the key elements that address that peculiarity of software project management, i.e. its complexity. Complex projects cannot be implemented alone, and that means that a distribution of the processes between team members. Accordingly, the latter implies the distribution of the responsibility of realizing the tasks that form the project. Project management cannot be led beyond the context of the organizational structure of either the organization or as in the present case, the project team. Behind this stand the responsibilities and the roles which the team members perform during the project. Accordingly, it can be stated that this is not only related to the issue of discipline, an essential component but, nevertheless, not critical in our case, but also to the issue of general management. It was understood by our team that there are no similar organizations as well as no similar projects. Accordingly, there are no universal organizational structures. Thus, the role and the responsibilities in performing specific tasks were tailored in the team, specifically to this project.
Among the issues that the team has to deal with, which are related to the conventional characteristics of WBS, in terms of the time span for each task and the number of people corresponding to each task. In that regard, two dilemmas arose, the first one is using the top-down approach, in which the activities should have been broken down into the smallest task needed for the project. Such an approach is ideal in this case as a more completed draft can be resulted from WBS, and additionally, the main features of the project were known from user stories, from which the complete picture was obtained, and accordingly, it would have been easier to structure down the tasks, add as necessary and reduce the possibility of missing a single task. For such a structure, it is usual to assign one person for the smallest tasks decomposed in WBS. On the other hand, the selection of extreme programming as the development tool and the life cycle of the project implied the emphasis on collaboration.
Extreme Programming emphasizes teamwork. Managers, customers, and developers are all equal partners in a collaborative team. Extreme Programming implements a simple, yet effective environment enabling teams to become highly productive. The team self-organizes around the problem to solve it as efficiently as possible (Brewer and Design, 2001).
Accordingly, other features of extreme programming and its basic practices imply that “[a]ll production code is written by two programmers sitting at one machine… [e]ssentially, all code is reviewed as it is written”, and that “[a]ny developer is expected to be able to work on any part of the codebase at any time” (Brewer and Design, 2001). Thus, it was decided that the main tasks in the project are to be done in groups, namely in pairs. Thus, it can be seen that the combination of these factors resulted in a little modification to the intended use of the WBS, in which instead of breaking down the task into the smallest elements possible, the team omitted the bottom level break down and the indication of the atomic tasks in the structure. In that regard, the second the third levels of WBS showed merely module work processes, assuming that each module will be implemented with two people working at the same time, i.e. writing the code and monitoring.
The implementation of the WBS levels as chunks or modules might have solved the issue with team formation, but at the same time, it posed new ones, in terms of time and cost estimation. Generally, the criteria are taken to determine that the WBS is completely included the following elements:
- Each module can be measured in terms of completion, for example, ringtone storage, admin webpage, ringtone browsing page, system testing, etc. In the latter example, all of the aforementioned can be at least given an estimation of three scales, i.e. 0-25 percent, 50 percent, and 100 percent.
- The tasks can be marked by starting and stopping points, i.e. the dependency of each task or module can be outlined, e.g. attaching the media player to the page comes only after the ringtone browsing page, the database module, etc. It should be noted that these points are relative, as in most cases they can be done in parallel.
- The activities are deliverable, i.e. there will be a certain output by the end of the activity, where for example, the process of writing the code of the login page, the admin page, the media player, etc, will result in that the completion of these elements being used as an output.
The only aspect through which it was difficult to determine the completion of the WBS is the cost and the time. The main reason for such aspect was stated earlier, i.e. the product is largely intangible, which is an overwhelming characteristic of software development. The aforementioned point leads to the next section of the project, which is risks, schedule, and cost.
Time Schedule, Risks, and Costing
There is a good reason for statistics stating that “[o]nly 9%-16% of IT projects are completed on time and on budget”, where over “50% of IT projects cost two times their original estimates” (MONOCHRISTOU et al., 2005). Additionally, looking in retrospective context, there are also pessimistic predictions, as “[c]ompanies that conducted IT projects in 1995 experienced a nearly 30% cancellation before they ever get completed, with an estimated total cost of $81billion” (MONOCHRISTOU et al., 2005). In that regard, the complexity of estimating the time schedule and the costing for the project was of great importance during the development of the project. A useful tool that was used during the estimation of the duration was PERT (Project Evaluation & Review Technique). This tool was useful in many ways, and in that regard, the following inputs were helpful in using PERT:
- An established starting and ending points in the project.
- Known processes.
- Known deliverables.
- The overall time span of the project (the maximum given time by the customer, which is three months).
Accordingly, the main issue was coming with an elapsed time for the activity, and thus, these variables were mainly estimated. The estimation was based on two points; the first one is that the implementation is the largest phase of the project, and the second one was in including the iterative planning phase in the activities. The latter was achieved through continuously repeating the testing activity, assuming that the customer might change the requirement. In that regard, such assumptions were accordingly added to the risk section and thus, the testing phase was made as prevention. Establishing the dependency was another difficult task, where the initial goal was to make several activities made in parallel. Nevertheless, with the implementation of the iterative planning, through repeated testing, it was decided that the stage of the planning will be sequential. The result of the PERT led to the formation of the Gantt chart. In that regard, it should be noted that the usage of the sequential process led to that the critical path coinciding with the project’s duration.
The costing of the project due to the inexperience of the team was mainly implemented through the method of analogy. In that regard, the costs that were taken were mainly based on the average salary of the needed staff, multiplied by the estimated duration of the project. It should be noted that estimation was the main basis for the costing methodology. Accordingly, the estimation of the resources considered such risks as absenteeism, in which the best solution was to considering the working in pairs mode, where the assistant will replace the absent team member.
Conclusion
It can be concluded that the experience in managing the case study project was beneficial in terms of realizing the main complexity of software project management. In that regard, it can be stated that despite the absence of systemic approaches, the experience gained, can be used at least in the aspects of estimation, closing the gap between the planned efforts and the results.
References
BREWER, J. & DESIGN, J. 2001. Extreme Programming FAQ [Online]. Jera Design. Web.
CADLE, J. & YEATES, D. 2004. Project management for information systems, Upper Saddle River, NJ, Financial Times Prentice Hall.
DEVEDZIC, V. Software Project Management [Online]. School of Business Administration. Web.
FUTRELL, R. T., SHAFER, D. F. & SHAFER, L. 2002. Quality software project management, Upper Saddle River, NJ, Prentice Hall.
JALOTE, P. 2002. Software project management in practice, Boston, Addison-Wesley.
MIKEWOOLDRIDGE. LECTURE 5: SOFTWARE PROJECT MANAGEMENT [Online]. Web.
MOCHAL, T. 2010. Defining project goals and objectives [Online]. MileStone Professional. Web.
MONOCHRISTOU, V., VLACHOPOULOU, M. & MANTHOU, V. 2005. AGILE SOFTWARE PROJECT MANAGEMENT ETHODOLOGIES. PROSPECTS OF THE GREEK IT MARKET [Online]. The 7th Balkan Conference on Operational Research. Web.
Project Management Work Breakdown Structure [Online]. Online Project Management. Web.
QSM. 9 Keys to Effectively Managing Software Projects [Online]. QSM. Web.
TSUI, F. F. 2004. Managing software projects, Sudbury, Mass., Jones and Bartlett Publishers.