Project Management Portfolio For The Project Initiation

Roles played during project initiation phase

Discuss about the Project Management Portfolio for The Project Initiation.

The first part was getting a project title and having it approved, an activity that took three hours; and I operated as a facilitator and project manager, as well as a programmer. Being a facilitator requires engagement and involvement in project inception and getting it approved; the challenge when assuming the role of a facilitator was that it requires the user to have other skills such as interpersonal, communication, and involves managing teams (Mathis, 2016); very little technical skills are required.

At the project initiation phase the author played the role of a programmer, a project manager, and a test engineer. During project planning and gathering resources that lasted five hours, I played the dual roles of a project manager and a programmer.  This is a crucial part of the project management because it must be gotten right as planning is crucial to the success of any project, according to Alexander (2015); it involves detailed planning and securing the necessary resources. However, being a project manager is tougher than being a programmer; the former requires organizational and people skills while the latter requires technical skills for which I am proficient. At the project kickoff, I was both a programmer, project manager, and test engineer for six hours; again the technical roles of being a test engineer and programmer were comfortable, unlike project management, but I was beginning to get the hang of it. At this stage, the challenge of identifying the expected outcomes and overcoming the anxiety that comes with getting a project off the ground.

The step involving analyzing the existing project version that involved evaluating existing systems and how users interacted with them, an activity involving extensive evaluation to have the correct picture. I was a project manager as well as programmer for the duration of eight hours and it involved identifying and documenting the existing project and one of the challenges was that it was tedious and time consuming. A high level definition of the existing system were analyzed and documented, as recommended by ‘MITRE’ (2016). I was a programmer when making weekly progress reports that required updating and making reports on progress by submitting weekly progress reports for four hours. The challenge with this task is that notes have to be taken during each activity as key events and occurrences are likely to be forgotten if notes are not taken regularly; developing the report took a good four hours. Agendas had to be developed for meetings and this took eight hours, a period I was programmer and test engineer; the challenge was reaching a consensus with other group members on what was important and relevant to the project. The progress made was presented and the challenges faced included putting together and making the presentation; the author for instance is not a very good public speaker and making the presentation was obviously a challenge, despite making the necessary preparations. I was a project manager for two hours and although still challenging I was learning fast.

Analyzing the existing project version

The user requirement documents were then developed; this activity took four and a half days and entailed eliciting user needs through interviews and observation as well as group discussions and research on technical white papers; I was programmer at this point. Getting to obtain the actual user needs was a challenge because some users would not easily define what they needed, hence the use of the various methods. Writing the requirements in a text document in natural language also had its challenges because based on interviews ad observations, using natural language was at times laden with ambiguity and communicating requirements to team members in an easily understandable manner for all was a challenge.  Natural language use in describing user requirements is sometimes laden with challenges such as confusion in detailing functional requirements (Sommervile, 2008). To obtain user requirements, a ten hours user requirement workshop was held where open discussions was done to elicit user needs; a draft user requirements document was then developed based on the discussions. As the project manager, I was involved in the user requirement specifications drafting over one day based on the workshop explaining the need for a new system and putting the product into context. The document also defined, in abstract terms, what the finished product should be (Smith, 2012).  The user requirement draft was then drafted and reviewed, amendments made and then signed off. A review of the requirements is important for examining whether all the requirements have been identified and their needs met (Levy, 2016), a process that took ten hours and I was the project manager as well.

Meetings were then held to review and discuss a solution; the steering committee met for six hour to deliberate on the issues covered and raised so far and to set the agenda for the next phase of the project. I was a test engineer and programmer in that period, jobs that were complementary and gave me few challenges. A meeting with the project board that took a total of twelve hours was held during which the draft requirements were discussed and extra input incorporated into the document; I was a test engineer, project manager, and programmer. The meetings entailed negotiations and discussions on the project and entailed a lot of diplomacy and explaining to convince the board and  other stakeholders that the user requirements had been captured and the project should proceed. Following these, a project proposal and plan were developed over one day; the planning section had its difficulties in determining time lines, resources, and deliverables, but nonetheless, was overcome. Writing the proposal had the additional challenge of not being sure if it will be accepted, however, the problem was diagnosed in-depth and a solution to user requirements proposed to let the client know what is being proposed (Marsic, 2011), marking the end of the project initiation and planning.

Developing user requirement documents

The technical design phase took five and a half days where I was the programmer as well as project manager; it entailed developing the software tool requirements where the requirements and dependencies of the clients’ system at specific times was listed before the actual design and development. This is an ‘insurance policy’ that makes certain that  both parties understand the requirements; the document precisely detailed the functions and capabilities of the proposed upgrade solution and the constraints the system must operate within (Le Vie Jr., 2010); (David, 2014).  The challenges faced in this phase included constant volatility in requirements, developing a suitable process, what technologies to employ, professional and ethical challenges and managing design influences. As a test engineer and programmer, I did feasibility assessment of the functionality and practicality of the proposed upgrade solution was undertaken to uncover the weaknesses and strengths of the proposed solution rationally and objectively (Thakur, 2016). Also, the opportunities and threats were evaluated and the historical background, product description, and policies documented. The challenge was in classifying opportunities and threats as well as strengths and weaknesses as some weaknesses were also opportunities. The list of reports that required upgrading were also identified and documented in a process that took ten hours where I was programmer and test engineer; the challenge was to ensure the updates met the objectives and did not constrain the operations of the entire system, while the business objects upgrade took two days before the systems’ quality was assessed and assured. The challenge during the upgrade was getting everything right and small hiccups requiring the upgrade to be restarted on two occasions.

The next process was the technical upgrade that took a total of 17 days; developing a suitable approach to the actual BO upgrade took two days where I was a programmer. The challenges faced included determining the personal, secured, and shared connections, determining the correct hierarchy, and choosing the best approach for the entire upgrade (Basu, 2016). As a programmer and test engineer, I also faced included developing and testing code using different languages;  the debugging phases for software development were a challenge at times. I was involved in the development of the list to upgrade as a programmer and test engineer, a process that lasted two days and the challenge was in developing the list as it required checking and re-checking several times. Testing software would result in bugs that required re-programming to get rid of and this is always a challenge; further time constraint made the tasks challenging. I was a programmer involved in migrating the BO that took six days where migration from databases took place; the challenges for this phase were numerous, including dealing with system criticality,  handling the size of the project, managing the schedule and project resources, and ensuring data integrity and security were maintained all through. For five days, I was a programmer and test engineer as well as project manager and was involved with identifying and fixing BO migration issues, including non-compatibility, slow-downs and loss of integrity of some data and challenges included identifying missing or corrupted data and making corrections. The challenges for this phase included identifying the exact issues, as some were not easy to identify. An upgrade completion report was then developed over ten hours, and because notes had been taken, there were no major issues in developing the report. Having migrated the BO and sorted some issues arising represented the technical migration milestone for the project .

Technical design phase

A quality assurance was done for two days where I was a test engineer and it involved creating QA reports for the new migrated BO and ensuring the data warehouse was optimally running. The challenge faced was using test data warehouse for the QA report. User Acceptance testing took two days where I was also test engineer and involved verifying the solution was working for the users; the challenge was that some issues could not be verified since some users were new to the migrated system. The testing report was generated over ten hours while I was test engineer detailing the performance of the system based on the QA and user acceptance tests. The challenge in generating the report was having all aspects included and reconciling user acceptance tests with the reality that some users were still not familiar with the new system and so it could or could not be treated as requiring more refining (Naik and Tripathy, 2011). Completion of the testing phase marked the testing and  technical upgrade milestone.

The next activity entailed training where I was test engineer and programmer; training is important in improve productivity and performance of employees and reducing stress associated with a new system (Bickerton, 2014). this involved developing a training plan and curriculum and developing a schedule for the training; a process that took a day. Developing the presentation materials and making presentations to the staff took a total of twelve hours; I was programmer and project manager. The challenge in developing the training schedule and presentation was in determining exactly what needed to be covered in the training given the time constraints. Further, there was no way to asses user grasp of the system and it was left for future administrators to continue with the training.  As project manager and programmer, developing the business objects administrator user guide took two days; the administrator user guide is important for the administrator to give support (technical) to the users of the system. In developing the user guide, the basic and complex tasks as well as possible issues that will require assistance. This entailed documenting operational procedures and rules  and the challenge was in identifying and predicting issues that may arise when users work with the new system (Fischhoff, Brewer and Downs, 2011). Completion of the training schedule and developing the administrator user guide marked the achievement of another milestone on training the users and developing a support manual.

Technical upgrade process

The next step involved the development of progress reports where I was programmer and test engineer developing the technical progress reports; progress report number I took ten hours and involved writing about the progress made up to the user requirement documentation; it entailed updating past reports and having all changes made reflected in the new report. The challenge was in developing a report with relevant facts and information without overlooking any important issue. The second progress report covered up to the technical upgrade and took five hours to develop; as test engineer and programmer, this was not challenging because the initial notes had been taken and I had a good grasp of the technical aspects for the project. The third progress report took five hors and covered the implementation while the fourth report also took five hours and covered the migration and training schedule. Writing the reports were not a challenge, except that in some instances, notes had been misplaced or not taken. The reports also required a lot of time, more than what was allocated and this required extra exertion and hard work to complete on time and present. Progress reports are essential for showing metrics for the whole project implementation and gaging overall performance (Pratt, 2016).

The close out phase took a total of 12 days and I was involved in developing the final project closure report as project manager, test engineer, and programmer. The report involved writing down the activities undertaken, challenges faced, and operational procedures for the migrated BO. The report also included the training done and the materials developed for the training as well as the roll out and any unique experiences. The project report also includes a budget of what was spent as well as the resources used (Dinsmore and Cabanis-Brewin, 2011). The entire project closure report took ten days to develop and had the challenge of having fewer resources (human resources to write the report). Further, since different people wrote the report parts which was then combined into a single report, there were challenges in maintaining the document flow and some areas had to be changed. This required a lot of time resources to accomplish. The presentation document was developed over a day and the challenge with this again was time constraints and ensuring that all items for the whole project were covered.  There was apprehension since the client had to accept the report which would automatically mean the software delivery would be accepted. The final progress report was developed over three days and entailed  nailing down essential and important content to meet the expectations of the intended recipient. The reports were made in a simple manner and fine tuned for the consumption of the audience; this is because progress reports can be long and the intended audience is just interested in knowing the important facts (Redmond, 2016). software was delivered over a four day period and mostly involved installing the software system-wide and ensuring everything was running, as well as attaching the necessary documentation and licensing requirements. Some challenges faced include having to reorganize operations in order to deliver the software fast and on time. Overall, the major challenges for the whole project included time and resource constraints and the training and user requirements and documentation phase, as well as having to meet deadlines and develop status reports. Agile methods were adopted in some instances to ensure timely delivery of the software (Chow and Cao, 2008). the end marked the achievement of the project closure milestone. 

References

Alexander, M. (2015). Planning is key to project management success. [online] CIO. Available at: https://www.cio.com/article/2932987/project-management/planning-is-key-to-project-management-success.html [Accessed 7 Oct. 2016].

Basu, R. (2016). Top 30 BusinessObjects interview questions (BO) with Answers. [online] Dwbi.org. Available at: https://dwbi.org/analysis/business-objects/69-top-businessobjects-interview-questions [Accessed 7 Oct. 2016].

Bickerton, P. (2014). The Importance Of Training Staff When Upgrading IT Systems. [online] Saxons Blog. Available at: https://www.saxonsgroup.com.au/blog/tech/the-importance-of-training-staff-when-upgrading-it-systems/ [Accessed 7 Oct. 2016].

Chow, T. and Cao, D. (2008). A survey study of critical success factors in agile software projects. Journal of Systems and Software, 81(6), pp.961-971.

David, K. (2014). Socio-technical design of ubiquitous computing systems. Hoboken: Wiley, pp.185-186.

Dinsmore, P. and Cabanis-Brewin, J. (2011). The AMA handbook of project management. New York: American Management Association.

Fischhoff, B., Brewer, N. and Downs, J. (2011). Communicating risks and benefits. Silver Spring, MD: U.S. Dept. of Health and Human Services, Food and Drug Administration.

Le Vie Jr., D. (2010). Writing Software Requirements Specifications (SRS) | TechWhirl. [online] TechWhirl. Available at: https://techwhirl.com/writing-software-requirements-specifications/ [Accessed 7 Oct. 2016].

Levy, D. (2016). Software Requirements Specification, what you NEED to know. [online] Gatherspace.com. Available at: https://www.gatherspace.com/static/software_requirement_specification.html [Accessed 7 Oct. 2016].

Marsic, I. (2011). Software Engineering Project Proposal. [online] Ece.rutgers.edu. Available at: https://www.ece.rutgers.edu/~marsic/Teaching/SE/proposal.html [Accessed 7 Oct. 2016].

Mathis, K. (2016). Choosing the Best Team for Your Project. [online] Project Smart. Available at: https://www.projectsmart.co.uk/choosing-the-best-team-for-your-project.php [Accessed 7 Oct. 2016].

‘MITRE’, (2016). Eliciting, Collecting, and Developing Requirements. [online] The MITRE Corporation. Available at: https://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/requirements-engineering/eliciting-collecting-and-developing-requirements [Accessed 7 Oct. 2016].

Naik, K. and Tripathy, P. (2011). Software testing and quality assurance. Hoboken, N.J.: John Wiley & Sons.

Pratt, M. (2016). How to Write a Progress Report. [online] Computerworld. Available at: https://www.computerworld.com/article/2560843/it-management/how-to-write-a-progress-report.html [Accessed 7 Oct. 2016].

Redmond, R. (2016). How to Report Status on a Project. [online] Project Smart. Available at: https://www.projectsmart.co.uk/how-to-report-status-on-a-project.php [Accessed 7 Oct. 2016].

Smith, R. (2012). Writing a Requirements Document For Multimedia and Software Projects. [online] Center for Distributed Learning. Available at: https://www.cdl.edu/uploads/Qd/S6/QdS615B1DcnwRZlnSuTDnQ/writing-requirements.pdf [Accessed 7 Oct. 2016].

Sommervile, I. (2008). Problems with natural language for requirements specification. [online] Ifs.host.cs.st-andrews.ac.uk. Available at: https://ifs.host.cs.st-andrews.ac.uk/Books/SE9/Web/Requirements/NL-problems.html [Accessed 7 Oct. 2016].

Thakur, D. (2016). What is Feasibility Study? Types of Feasibility. Explain Feasibility Study Process. [online] Ecomputernotes.com. Available at: https://ecomputernotes.com/software-engineering/feasibilitystudy [Accessed 7 Oct. 2016].