Project Management for Business, Engineering, and Technology - Essay Example

Software Project Management Student’s Name: Course: Tutor’s Name: Project description The project analyzed in this essay was intended to provide a software that would enable consumers, retailers and dealers access online reservations to hotels, cars and air tickets. Six people drawn from the student participants and personnel from the client company made up the work team. Managers responsible for providing direction and overseeing the project were drawn from the university faculty. Right from the onset of the project, the students, their lecturers, and the personnel from the client company intended to conduct research in the identified area, with the aim of providing prototype software that would serve the interest of the client company well. As such, participants intended to attain an archetype of an ideal software product that would enable the client company conduct online bookings and reservations in an efficient, fast, and timely manner. The client company contributed to the project by employing participants for inclusion in the project, and allocating a small budget to the project. Despite the support from the client company, the project faced some challenges, which included the inexperienced state of students who participated in the project and the client company’s unfamiliar state with online reservations or bookings. Overall, the project that lasted for nine months was intended to come up with an innovative software prototype, which could be implemented by the client company albeit on a trial basis. The innovation requirement meant that the project participants had to research other software programs available in the market, identify their strengths and weakness, and develop a software program prototype that was more superior, flexible, convenient and affordable that others in the market. Problem description The project was laden with multiple problems that mainly occurred due to lack of experience by the participants, inadequate planning, limitations in times and resources, and the seeming non-committal attitude adopted by the client-company. Specifically, the inability of the client company to state its exact requirements or preferences for the project proved to be a major problem. Secondly, the inability of participants to organize the project well was also another major problem. The third problem on the other hand was caused by the workgroup’s inability to create a good schedule and stick by it. The fourth problem was caused by the lack of a risk management plan. As such, some of the risks experienced in the course of the project caught the participants unawares. Finally, the fifth problem occurred because the workgroup failed to have sufficient project control mechanisms. As such, group members failed to agree on how best to achieve set targets or even overcome challenges experienced in the course of the project. Using the example provided by Nicholas and Steyn (2008, p. 137) regarding software product development by Microsoft, it is rather obvious that our group was on the right track by scheduling a planning phase that lasted 9 months. During such a phase, the authors observe that Microsoft develops a “vision statement, specification document, and plans for marketing, integrating components from other groups, testing, and documentation.” Problem 1: Client Company’s inability to state its exact requirements or preferences for the project According to Nicholas and Steyn (2008, p. 158), participants in a project need to answer the “what, for how much, and by when?” questions during the planning process. For the identified questions to be answered fully, performance targets, project deliverables, time and cost estimates as well as other sought results have to be clear to the workgroup. However, clarity on such matters can only be attained if the client has clear expectations about the project. In our case, the client did not have any expectations about what the result of the project would be, thus making our task even harder. Without the client company having clear expectations about the project, our workgroup did not know the criteria that the client would use in determining the acceptability of deliverables or the final software. The client lack of clear expectations about the product created further problems for the work team since it was difficult to define the tasks, activities, and objectives of the project. Creating a project organization was also difficult since the kind of project and its main goal was changed once. Consequently, the time allocated to the project was wasted as the workgroup had used some significant time working on the initial project only for the client company to state that it wanted a different kind of project. As Nicholas and Steyn (2008, p. 161) observe that defining the project scope is essential in planning a project. Specifically, the authors advise that contextualizing the needs and requirements of the client is important in “determining the objectives, deliverables, and major tasks of the project.” Additionally, understanding what the client expects from the project enables people working on the project to determine the amount of technological, financial, and time resources needed to actualize the project goals and objectives. Without proper expectations from the client-company therefore, our workgroup did not have the necessary understanding required to define the project scope. Consequently, the workgroup was not able to specify inclusions or exclusions of the project. According to Nicholas and Steyn (2008, p. 161), inclusions are activities that must be undertaken in a project in order to attain the sought-after results, while exclusions are the activities that should not be dealt with by the project. In most cases, exclusions include responsibilities that should be handled by the client company, while inclusions are those responsibilities that fall squarely under the contractor’s jurisdiction. Notably, the client-company’s employees who participated in the project did not actively contribute to its outcome; rather, they assumed an observational role as the student participants who were incapacitated by their lack of decision-making powers handled all the work. Had there been a clear stipulation of inclusions and exclusions however, the student and employee participants could have had distinct duties in the project, which could have enhanced their respective participation in the project. The client company’s inability to state its exact requirements or preferences for the project also crippled the workgroup’s ability to create a statement of work (SOW) as suggested by Nicholas and Steyn (2008, p. 163). The SOW contains succinct project description that includes the objectives, project scope, the project impact, validation, and management requirements. In some cases, the SOW may also contain management procedures necessary in planning and any changes or risks that may come up in the course of project design. Further, the SOW contains budget estimates, project schedules, and staffing requirements and responsibilities. If our work team had sufficient information from the client-company to develop the SOW, the client-company could have had a chance to approve or disapprove the project before commencement. This would have in turn saved the wasted time and efforts that went down the drain when the client company altered the first project. The lack of dialogue between project participants and the client-company further complicated issues since the communication needed to foster a successful working relationship was lacking. Consequently, the management of the client-company imposed a project deadline that did not fit into the project plan initially envisaged by the participants. Since the participants had already created a work breakdown structure (WBS), they had to ditch it in order to satisfy the client-imposed deadline. The ditching of the original WBS interfered with the schedules, plans, and targets and envisaged outcomes that the student participants had on the project. Consequently, the project manager found it hard to delegate projects to specific participants, and this compounded the work schedules even further. In a bid to comprehend and deliver on the client-company’s expectations, the participants held time-consuming meetings, with division of work being the main agenda. Unfortunately, such meetings did not yield substantial results in spite of taking up much time that would have been otherwise used in meeting vital software project milestones. Problem 2: Project organization The project suffered a serious lack of project organisation. As such, the workgroup did not agree on the necessary planning steps for the attainment of specific project goals and objectives. The lack of project organization was to a great degree caused by the group’s inability to delegate responsibilities to the appointed managers. This in turn meant that the managers failed to assume responsibility towards steering the team and ensuring that all work activities were accomplished in an effective, efficient, and timely manner. Notably, those participants chosen to occupy top-managerial positions during the project did not fully comprehend the precise nature of their responsibilities. The situation was further complicated by the fact that top managers did not participate in meetings, implying that they were not part of the decision-making process. Overall, what could have been a properly organized project became a spectacle of confusion especially since the project manager who was chosen from the student participants did not have any legal decision-making powers. The inclusion of customer participants whose tasks and responsibilities were vague to the rest of the participants further complicated the situation. At some point in the project, one customer participant, perhaps out of disappointment at the lack of direction that the project was taking, assumed some decision-making powers. However, this only worsened matters since the project now had two managers, and none of them offered the group the much-needed leadership. The inclusion of personnel from the client-company as co-developers of the project also posed challenges to the proper organization of the project. Specifically, the personnel failed to live up to their title as ‘co-developers’ and instead assumed passive observational roles. This in turn meant that the rest of the workgroup could not rely on them to accomplish any identified tasks in the project. Considering the workforce requirements of developing software, this project called for some training of all participants since the client-company did not hire any experts to guide the rest of the team members. However, the workforce requirements were overlooked and it was assumed that any project participant was fit enough to assume any role in the project. This in turn compromised the quality of the work breakdown structure and consequently caused a delay in all identified schedules. Additionally, failure to identify individual skills, strengths, and weaknesses in participants meant that the project tasks were delegated in an ad-hoc manner. If a new requirement came up, a task was fixed in the existing schedule, and any participant with enough time to handle the same was given the responsibility of working on it. Problem 3: Inadequate Schedule The workgroup failed to come up with a comprehensive schedule, and consequently, not all participants fully comprehended or appreciated the tasks and the milestones that the project intended to meet. The magnitude of this inadequacy is captured by Nicholas and Steyn (2008, p. 176), who argue that “Scheduling the work elements is the most important step in planning because it becomes the basis for allocating resources, executing work, tracking project performance and fining on time. Schedules show the timing for work elements and when specific events and project milestones should take place.” The failure to come up with a detailed schedule was partly caused by the participants’ inability to utilise formal ways of creating a project plan. The consequences of this inadequacy were evident from the unrealistic deadline that participants initially set, the lag witnessed throughout the project, and the inability of project participants to set specific milestones that were essential in completing the undertaking in good time. The insufficiency of the schedule that the project utilised was further worsened by the fact that participants failed to consider management activities necessary in the implementation phase of any project plan. For example, during schedule formulation, participants did not consider the important role of developing project reports, which ideally, should be forwarded to the management, or the importance of reviewing completed job tasks in order to determine whether they had contributed to the overall project goals and objectives. Three months to the end of the project period, the type of project was changed and this called for re-planning the entire project. Unfortunately, the project participants in their haste to complete the project within the remaining months did not deem it necessary to plan another schedule. Consequently, the participants did not have a convenient schedule to work with, and this only brought about more delays and confusion in the workgroup. Problem 4: Risk Management Like other projects, the software project was not without its share of possible risks. However, the participants did not deliberate on any risk assessment or identification exercise while starting the project, and consequently the group lacked the capacity to predict the consequences of, or manage the different possible risks. When the workgroup lost a team member after one month into the project due to injuries sustained in a car accident, the team did not have a strategy of dealing with such an occurrence. As such, the participants wasted valuable time coming to terms with the loss and regaining the motivation to proceed with the remaining part of the project. The team expected to recruit a replacement, but top management and the client-company declined. As such, the workgroup had to delegate the tasks meant for six participants among the five remaining participants. Towards the end of the project, one more person quitted, making the tasks even more demanding for the remaining participants. The lack of a risk management strategy also meant that the workgroup did not foresee some of the challenges that the project would come across. For example, being a project initiated by students, we had the impression that the client-company did not consider it a weighty-matter and hence did not dedicate as much attention and resources as we would have preferred. This was evident from the client-company employee’s attitudes towards the project. Some examples of how this occurred include the client-company’s failure to negotiate with Polcard - the firm that would have necessitated online credit card payments, and its failure to negotiate for authorization with travel services booking firms. The client-company’s inaction meant that the module designed to enable online payment could not be tested, and neither could the software’s efficiency as a hotel-booking tool be verified. Problem 5: Inadequate project control Project control puts emphasis on the ‘scope, quality, schedule, and cost’ (Nicholas and Steyn, 2008, p. 170). The participants’ failure to clearly define or contextualise the system requirements jeopardised the probability of them defining the project scope in a succinct manner. Without a clearly defined scope, it was difficult for the participants to schedule job performances, and even harder to estimate the costs needed for the same. As such, the participants could not vouch that the project would result in quality results. The lack of proper project analysis further compounded issues because the participants did not know if their approach was acceptable by the client-company or not. Although the work team was small, inefficient communication brought about several inconsistencies that jeopardised the team’s ability to control the project. For example, the student participants could say one thing during their closed-door meetings, and then say a different thing in their meeting with the consumer participants. The different viewpoints were confusing and a disadvantage to the smooth running of the project. The consequences of the inconsistencies were evident in the project results since even after achieving milestones in some cases, the results were usually unsatisfactory. Whenever the team had unsatisfactory results, remedies for the same would be sought, and this led to the development of new schedules meant to correct past mistakes. Unfortunately, with no clear leader to award project responsibilities to specific participants, most of the remedial tasks remained unaccomplished. Overall, new problems kept copping up, and the limited workgroup was unable to handle them all in a satisfactory manner. Ideally, any project should attain identified goals and objectives by sticking to laid-down plans (Nicholas and Steyn, 2008). Unfortunately, the software project lacked clear goals and/or objectives, and did not even contain a comprehensive schedule or plan. This meant that team members could not intentionally influence the direction that the project took. The problem was further compounded by the fact that the project manager was drawn from the student participants. As such, she lacked the experience necessary to lead the group, and the legal authority needed to make decisions on behalf or with consultation with other participants. The uncaring attitude of the top management of the client-company as was evident in their seldom review of work results also gave the impression that the project was inconsequential. This did nothing to boost the motivation of participants (students, employees and customers). If anything, the client-company’s attitude only dampened participant’s motivation, making them less enthusiastic to contribute towards it fully. In the end, the client-company was not sure that the project was ideal, or whether something more could have been done to improve it. The students’ lecturer also failed to express his sentiments about the project, thus leaving students in the dark regarding their project or future work. On their part, the consumer participants were not consistent in their attendance of review meetings, and even when they did, most lacked the knowledge needed to review, criticise or recommend specific project actions. Overall, the project lacked internal and external controls, which were necessary in enhancing its chances of meeting the aims and objectives set at the project conception phase. Finally, the project manager’s inability to control the workgroup, or offer guidance on vital areas meant that no one was in charge of controlling the project. Ideally, all participants would have understood that the project manager was essential in providing direction, control and leadership to them if the project was to succeed. However, most of the participants treated her as if she was an enemy hence frustrating any of her efforts to foster cooperation among participants and therefore control the work in the project. Unfortunately, this problem was not resolved, and its negative impact on the overall quality of the project was all too apparent. Proposed ways of improving the overall quality of the project, and preventing problems from occurring According to Nicholas and Steyn (2008, p. 157), each project must be clearly defined for it bear unique results intended to serve a specific purposes. The clear definition of the project lays the groundwork for a project scheme that identifies what each participant must accomplish. In addition, the definition helps participants construct a project plan with a specific output in mind. Project control on the other hand is geared towards ensuring that participants do everything that is required to make the project a success. To address the first problem, which has been identified as the inability of the client-company to stipulate the exact requirements of the project, the participants could have benefited from Nicholas and Steyn’s (2008, p. 161) advice on the importance scope definition. According to the writers, scope definition “is the process of specifying the breath of the project and its full span of outposts, end-items, or deliverables”. With a proper scope definition in place, Nicholas and Steyn (2008, p. 161) argue that there is little chance of misunderstandings or false expectations between the client and those working in the project. If our team had a scope definition, chances are that the client could have been better informed about the software project, hence enhancing the likelihood that the client would have had clear requirements about the project. It would also have made it easier for the participants to voice their expectations regarding possible constraints, assumptions, and any expected input, monetary or otherwise, from the client-company into the project - hence minimising the chances of misunderstandings between the two parties the course of the project. By embracing Nicholas and Steyn’s (2008, p. 190) advice regarding the use of a project charter, the software project could also have garnered the necessary support from the client-company, hence increasing the chances that employee participants would have taken a more active role in the project. According to Nicholas and Steyn (2008, p. 190), the project charter is a document used in the internal operating environment by the contractor to describe, announce, and get formal authorization for the project to begin. By insisting the use of a project charter, the project participants would have indirectly encouraged the client-company to re-evaluate its software needs and hence come up with specific project requirements. After ditching the first WBS due to its incompatibility with the client-imposed deadline, the team could have created another work breakdown structure with four elements as proposed by Nicholas and Steyn (2008, p.164) whereby, the main project would have been divided into subprojects, activities, and work packages. According to the authors, the subdivisions in the WBS should conform to all the work areas or deliverables identified in the project scope. Had the participants created another WBS, the project could have had a better chance of success since Nicholas and Steyn argue that it allows teams to identify the “requirements, deliverable or system of the project and its major subsystems and components” (p. 164). With a clear WBS, it would also have been easier for the team to distinguish between project requirements that the client-company needed to meet, and those that the project participants needed to handle. The WBS would also have enabled the team working on the project to share project responsibilities more efficiently. As Nicholas and Steyn (2008, p. 169) observe, a good WBS contains work packages that are clear and comprehensive, thus allowing participants to know their exact duties in the project. Additionally, the work packages list all the resource requirements, thus making it clear to the contractor what is expected of him/her, in terms of materials, facilities, equipment, skills and labour. The work packages also include cost estimates, and this would have made the client-company of the monetary resources required to make the project a success. Task-related responsibilities, outcomes, inputs, quality assurance, risks and any other additional detail needed towards making the project a success would also have been stipulated in the work packages. As Nicholas and Steyn (2008, p. 172) observe, “The list of work tasks developed from the WBS is used to create schedules, budgets, and other elements of the plan.” As such, if participants in the software project had taken time to re-create a work breakdown structure, chances are that they would have had an easier time creating the budget, schedules and other fundamentals of the project plan. The software project could also have benefited from a responsibility matrix, where all the tasks identified in the WBS should have been given to the identified participants. Ideally, the responsibility matrix identifies who has the primary responsibility, the secondary responsibility, notification rights, or approval rights to each task. With the matrix in place, every participant would have known what others expected of them. This would in turn have made the participants more committed towards their responsibilities in the project, hence resolving the problems that hindered the proper project organisation. Possible scheduling and project control solutions According to Nicholas and Steyn (2008, p. 177), there are two types of schedules that can be utilised i.e. project schedules and task schedules. Project schedules show major activities necessary in the attainment of project activities and are therefore the upper management and project managers in the client company could have benefited from using such. Task schedules are on the other hand more detailed, and show specific activities essential for the completion of activities or work packages. According to Nicholas and Steyn (2008, p. 177), task schedules enable low-level managers to focus on specific tasks, and thus motivate people working on the same. The use of a Gantt chart as indicated by Nicholas and Steyn (2008, p. 179) could also have provided a solution to the scheduling challenges encountered by the project team. According to the writers, a Gantt chart is a simple depiction of the various tasks in a project, and “gives a pictorial model of the project”, making it easy for the planner to express his/her ideas, and the user to comprehend them with relative ease. In developing the Gantt chart, the project participants could have listed the work element of the project sequentially after considering elements that needed to be completed before the participants started working on the others. As Nicholas and Steyn (2008, p. 178) observe, all activities listed in the WBS should ideally appear in the Gantt chart. This would have in turn served to resolve the inadequate project control witnessed in the course of the project, as it would have made it easier for the participants to understand their responsibilities, hence giving the manager an easier task. Additionally, the animosity that some participants had against the manager would have been avoided if everyone fully comprehended and appreciated their respective roles in the project. Possible risk management solutions Possible risks in the project could have been identified by developing ‘areas of risks and uncertainties’ as suggested by Nicholas and Steyn (2008). Here, the participants would have brainstormed on the possible risks areas and therefore developed strategies for dealing with any eventuality. As such, the loss of two project participants would not have dealt the project a big blow as it did. Benefits from techniques suggested by Nicholas and Steyn Though Nicholas and Steyn have emphasized the concept of developing WBS in its entirety, it is their suggestion about the development of work packages that seemed most relevant to the software project management. If the project team had taken time to develop the WBS, and by extension the work packages, it would have improved the overall quality of the project outcome in several ways: First, the work packages could have enabled participants to solicit the client-company’s input through the appointment of functional managers or other employees to be responsible for the project outcomes. Involving the employees more and giving them some responsibilities towards the final software product, would have made them more committed towards the project and hence justifying the title ‘co-developers’. Without specific responsibilities however, the employees’ involvement in the project was just cosmetic since they did not actively participate in the same. As a result, the workload sometimes overwhelmed the student participants, and this contributed to the inadequate outcome of the project. As Nicholas and Steyn (2008, p. 172) observe, influential employees’ approval of the WBS and the work packages enhances their commitment in a project, and consequently increases chances that project tasks will be handled accurately, and completed in good time. The second possible benefit that the project could have derived by following the guidelines suggested by Nicholas and Steyn is contained in the fact that the work packages would have enhanced the participants’ probability of completing all identified project tasks. According to Nicholas and Steyn (2008, p. 172) people should arrange tasks logically, and in accordance with how they relate to each other. As such, before proceeding to a different task, the participant must complete all predecessor tasks. If this was used in the software project, many of the incomplete tasks that were left hanging as discussed elsewhere in this paper would have been completed before the team could proceed to the next phase. Notably, this would also have enhanced the team spirit by encouraging participants to work together towards the completion of all project tasks. The third possible benefit is contained in the fact the work packages would have formed the basis for developing schedules and budgets necessary for the completion of the project in good time and satisfactorily. With a limited budget, lack of expertise, and limited time, it was highly unlikely that the team could attain maximal outcome through the project. However, by involving the client-company in the budget-making and scheduling processes, the team working on the project could have had a greater chance of convincing the senior management that the budgetary, time and human resources were well worth the effort since the software could have resolved some of the challenges experienced in the traditional modes of hotel booking and reservations. The attitude displayed by the client-company and its employees suggested that they perceived the project as a ‘student thing’ that had no real value for the company. This in turn suggests that the client-company did not fully understand the benefits that such software could bring forth. The fourth possible benefit could have been accessed from the fact that work packages enhance the probability of attaining better organisation in the project. As Nicholas and Steyn (2008, p. 172) observe, “Resources are assembled for and management responsibility delegated to individuals in each work package.” Consequently, such delegation of tasks would have resolved the project organisation challenges that the work team faced. Conclusion The inability by the client-company to stipulate its exact requirements, inadequate project organisation, inadequate schedules, lack of a risk management plan, and the inadequate project control are all problems that culminated in a software project that did not satisfy either the participants or the client-company. Notably, all the problems can be summed up in one short phrase: poor planning. Luckily, and for future purposes, Nicholas and Steyn (2008) have provided vital lessons for people who undertake software projects with the intention of serving different needs in the society, or as requested by clients. Among the lessons provided by Nicholas and Steyn include the fact that every project needs to be clearly defined in order to enable the participants and the contractor to agree on just what the end-result should be. Based on the project definition, the participants then devise a plan and decide on how to ensure that all functions needed in doing the project in the right manner. The first major mistake in the software project occurred when the client-company failed to express its expectations and requirements. As such, the project participants could not adequately identify the work tasks, schedules, responsibilities or budgets needed to make the project a success. Without a proper plan, the project participants as well as the client-company could not track or assess the progress of the project, and this made it even harder for them to recommend or take corrective actions. The aloof attitude adopted by the management and employees of the client company also made it hard for the project participants to follow planning steps as identified by Nicholas and Steyn since the student participants did not have the legal decision-making powers needed for such a project. Reference Nicholas, J.M. & Steyn, H. (2008), Project management for business, engineering, and technology: Principles and practice, Butterworth-Heinemann, Oxford. Read More