Post project review

This project was an attempt to create a portfolio in the format of a blog on the subject of project management. This project involved myself and my tutor, I was the one in charge of the project and had to report to my tutor to check up on the progress off the blog. The project had 3 sets of deliverables due, each set contained a combination of mandatory and optional deliverables with a set deadline. I had to choose the optional deliverables for each set and agree to a formative assessment deadline for each set with my tutorial tutor. Once a deadline had been chosen I had to stick to it, the projects deliverables had to be presented via the blog. In the blog I discussed:

  • project management principles,
  • definition of project management terms,
  • quality issues in project management,
  • the preparation, monitoring and management of a project plan
  • the various tools and techniques that can be used within and for a project

The optional deliverables I had chosen to do in set 1 was the glossary on project management terms and living with Alice. I chose these 2 deliverables because I felt that they would help me later on in the other deliverables especially the glossary terms, I also wanted to know what kind of tools one can use in a team project hence the choice of living with Alice. Both deliverables were very informative and required a lot of research in order to complete them, I learnt many project management terms and their definitions this has helped me understand what is involved in project management and I also learnt about the various communication tools that can be used in projects.

The mandatory deliverable was a project plan that had a project scope, milestone list, communication statement, risk management plan, quality management plan and a baseline statement. I found this deliverable to be slightly difficult as it required me to learn many things I did not know about or understand very well. I learnt quite a lot from this deliverable especially on how to manage and plan projects, I also learnt how to create a risk management plan and a quality management plan. All the deliverables in set 1 were finished on time for the formative assessment.

The were 2 mandatory deliverables for set 2, a case study on the London Ambulance system failure and an estimation of a project using FPA. The optional deliverables I had chosen were identifying the risks and code complexity. I learnt a lot from all the deliverables in this set, each deliverable had a different problem regarding project management. I learnt about how big projects fail, how to estimate using FPA, how to identify risks as a manager and how to calculate the complexity of a piece of software code. I chose the 2 optional deliverables as they seemed very interesting, I had never heard of calculating code complexity so I wanted to see what it was about and I chose identifying risks as it had many things similar to a deliverable in set 1. I completed all deliverables in this set in time for my formative assessment.

In the final set there was 1 mandatory and 2 optional deliverables. The mandatory deliverable was a post project review and the optional deliverables i had chosen was scheduling and a tricky choice. I had chosen the scheduling deliverable to learn about the techniques used in scheduling a projects, I learnt that there are 2 categories of techniques one to display the project schedule and the other to analyse the schedule. I chose the tricky choice deliverable as it had some relation to a deliverable in set 2. The mandatory set helped me learn how to critically analyse and review my findings. I completed all deliverables in this set on time for my formative assessment.

I did find it difficult in doing the FPA estimation deliverable as it was slightly confusing as to how one would calculate it, I overcame this by going through the slide and reading the extra material given by the lecturer. The code complexity was slightly difficult as well as i had know clue as to calculate complexity using the cyclomatic metric, to help me with this deliverable i searched online for the material and a guide on how to use the metric. Furthermore I also found most of set 2 difficult as i had to do a lot of research and did not know much about the deliverables in the set. I overcame this by reading the extra material and researching for more information on the internet and asking questions to the lecturer.

I tried my best to keep to the schedule i created however i would sometimes do certain deliverables for some sets at the last minute therefore the quality of work i did suffered. I should also have spent more time in choosing my deliverables for each set. I think i achieved some of what i said in the baseline statement, some of my work was very good others were satisfactory. I did keep the presentation of the blog neat and tried my best to use the correct grammar in my postings. I also researched each deliverable as best as i could to help my postings be coherent and well thought-out and also to argue my points clearly.

By doing this project i learnt what goes in to managing a project. I learnt to plan my work effectively and found out about the various tools, techniques, procedures and requirements of project management. I gained knowledge in the field of risk management planning and quality management planning. Furthermore i learnt how to critically evaluate my own work and learnt how to reflect upon my shortcomings. Recommendations for the future would be to keep to the project schedule and to not complete any deliverables at the last minute, also to research deliverables further.

A tricky choice

A large development project has been broken down to 5 sub-systems each coming in at 100 KLOC, however if they are developed together certain common utilities could be identified reducing the size of the system to 455 KLOC. From a time and cost point of view, which would be better to develop, 5 separate sub-systems each at 100 KLOC with utilities being repeated or one system coming in at 455 KLOC?

I would choose to develop the system together rather than as 5 different sub-systems because each sub-system comes in at 100 KLOC, together the total of the project would be 500 KLOC which means it will create more lines of code if done separately. More lines of code means more time spent on creating the system, more time spent equals higher costs for developing the system. Also each sub-system would need a manager to manage each project which will increase cost again. Furthermore creating separate sub-systems will mean utilities will be duplicated for each sub-system therefore increasing costs further.

It is better from a time and cost point of view to develop the system together as doing it separately increases the cost via duplication of utilities and increasing the LOC which would lead to increasing the amount of time spent on the project.

Scheduling

Introduction

This is a report on the different scheduling techniques that can be used to schedule projects and to find out what are the advantages and disadvantages of each technique, furthermore this report will discuss the term resource balancing and what techniques could help in resource balancing. Scheduling is deciding in advance when and where tasks will be performed, it is find out when a task should begin and end depending on its duration, predecessor activity, the resources available and the date the project is to be completed. There are a variety of techniques to use when scheduling a project. They fall into 2 categories, displaying the  project schedule and the analysis of the project schedule. Milestone charts, task lists, gantt charts and network diagrams are techniques that fall into the first category while critical path method, resource levelling, critical chain and PERT fall into the second category.

Findings

Milestone Charts fall into the category of displaying the project schedule, the chart displays key project milestones/events and is used to only display milestones. The milestones are related to project risks, milestones are passed when overcoming specific project risks i.e. completion of testing. The pros of a milestone charts is that it helps senior management track the project and helps task managers break down projects according to milestones allowing them to plan and track project activities. Good for large and complex projects, it helps scheduling reporting.. Disadvantages of milestone charts is that they do not show all relationships between milestones and they do not allow for the measuring of outcomes of changes and errors to the project/milestones while only improving the documenting of the errors.

Task Lists are also part of displaying the project schedule, it is used to inform project members of the tasks that they must work on and complete. The pros of task list is that it keeps the project members focused, it is good for large projects that have many members and it is one of the best methods to keep extended members busy. The cons of a task list is that it must be monitored to ensure members are doing tasks and tasks must be set beforehand. For projects with extended members the task list is best used to help with tracking and communicating with those members regarding tasks to perform.

A gantt chart is another diagram that can be used to display the project schedule. For a gantt chart, a bar chart is used to schedule tasks and track their progress. The left edge has the task and the top has the time it would take to complete the task. Each task is connected to the one below. Advantages of using a gantt chart are it is a good tool to present milestones/tasks and the time assigned to tasks, it is also good to use it to keep track of tasks completion. It is good for projects that have a clear schedule and accurate estimations. Cons of gantt charts is that if changes were made to the schedule it would require the redrawing of the gantt chart and also estimations must be done prior to creating the chart, furthermore resources assigned to tasks are hard to illustrate on a gantt chart.

Finally a network diagram is another scheduling technique to display the project schedule, it can be used to display the flowchart of the project tasks. It displays how tasks are related and which tasks need to be completed before moving to the next task. Advantages of network diagrams are that they can provide guidance to members regarding who is doing what task and what is the next task. Network diagrams are good for projects that have uncertain task and inaccurate estimations.The disadvantages of network diagram is that it is often used as a foundational technique, it can become very complex and can be costly to produce. More over it can also be very time consuming.

Critical Path method is part of the second category of project scheduling techniques. It is used to find out the shortest time it will take to complete a project or phases of a project. CPM will help determine the amount of time one would need for the project schedule. The pros of critical path method is that it helps to organize large and complex projects, makes relationships visible between project activities and calculates float for projects. Good for projects that have and know the amount of resources they need for the project. The cons of the critical path method is that diagrams would have to be drawn again if the plan has been changed, CPM does not account for resources and resource allocation and it can become large and complex for big projects.

Resource levelling technique is used to allocate resources where it is needed most in the project, it is a technique used to analyse the project schedule. Resource levelling ensures resources are used appropriately and applied to where they are needed. The advantages of using the resource levelling technique are the increase in the production process. It helps to identify spare resources and prevents over allocation of resources. Good for projects that are having difficulty managing resources. The disadvantages of resource levelling is that it can cause the loss of flexibility and increases the criticality of tasks.

Critical Chain is used to build upon analysis done by critical path and resource levelling technique. It is used to accelerate the project and ease the load on project management by re-prioritizing the work using simple tracking principles. The pros of critical chain it helps to plan resources and gives further control over the project. Good for projects that have constrained resources. The cons of critical chain is that every task becomes critical, the critical chain would need to be re-calculated if plan has changed. Also both critical path and resource levelling must be done beforehand.

PERT stands for Program Evaluation and Review Technique, it is used to identify the worst case and best case boundaries for the project, this technique is part of the analysis of the project schedule. It is also used to estimate the PERT for each task then using the task-PERT to create a project PERT schedule duration. The pros of using PERT it eases large project planning, it can be applicable to many projects and PERT will help pinpoint activities that need to be closely watched. The cons of PERT it can create complex charts and cause forecast inaccuracies.

Conclusion

The term resource balancing refers to applying resources within a project appropriately in order to prevent having tasks overusing resources. The techniques that would help to balance the resources within a project would be the resource levelling technique as it is used to allocate resources to  tasks and project. Also the critical chain technique will help with resource balancing as it used to identify the most constrained resource and to ease it by spreading the resources.

There are many advantages and disadvantages to each technique, depending upon the project objectives, risks and resources the project scheduler will need to choose which techniques to use to display the project schedule and to analyse the project schedule. The project scheduler can use a combination of techniques to determine the project schedule but it all depends upon the project.

Resources:

Projectmanagementguru.com (1960) Project Management Guru Schedule Planning. [online] Available at: http://projectmanagementguru.com/scheduleplan.html [Accessed: 16 Apr 2013].

Estimation using FPA

Assume the requirements analysis for a project written in Java has been carried out and has identified 20 use cases and 12 core classes that represent business objects. In addition 9 interface classes are needed in total 21 classes and 20 use cases.

a)What is the FPA for the above project with an adjustment factor for use cases of 7 and a adjustment factor of 11 for classes?

The FPA (Function Point Analysis) is an established technique for estimating the size and complexity of a software project.

Below is the calculated FP of the project:

FU = No of Use Cases,  FC = No of Classes,  WU and WC = Adjustment factors

FP = (FU x WU)+ (FC x WC)

371 = (20 use cases x 7) + (21 classes x 11)
 
Function Point = 371
 
b) Calculate the Adjusted FP with a complexity factor of 45:
 
0.65 AND 0.01 are constants, ∑Fi = 45 complexity factor
 
∑Fi = Fi are 14 factors, each with an (integer) value in the range 0 to 5 obtained in answer to each of the following questions.
 
FP adjusted = FP x (0.65 + 0.01 x ∑Fi )
 
408.1 = 371 x (0.65 + 0.01 x 45)
 
Calculate the line of codes:
 
60 is from the QSM table which can be viewed here http://www.qsm. com/FPGearing.htm
 
You need 60 lines of code per function point in Java. To calculate KLOC you times the FP by the lines of code per FP in Java.
 
60 x 408.1 = 24486 KLOC
 
c) Use COCOMO to calculate the required effort E, assuming the project is classed as semi-detached:
 
COnstructive COst MOdel is a relatively simple means of converting code size (in KLOCs) to effort in person-months and to provide an optimal project duration in months.
 
To calculate the required effort here is the formula: E = a(KLOC)b
 
a and b are taken from semi-detached software type from the table below:
 
pm
 
E = 3.0(24.486)1.12
 
107.8 person-months = 3.0(24.486)1.12
 
30% of 107.8 = 32.34 person-months for testing, integration and debugging
 
d) For the above project would 25 person-months be an adequate amount of effort for testing, integration and debugging?
 
According to Pressman (2000) the total effort required for testing, integration and debugging is around 30-40%.  It would take 107.8 person-months to complete the project assuming requirements analysis has already been done. 30% of 107.8 = 32.34 person-months from this calculation i can say that 25 person-months is not adequate and too little for the testing, integration and debugging. Testing, integration and debugging are important parts of the project, to limit the amount of time and effort spent here would severely effect the project goal, objectives and final product.
 
(e)If you were developing a quality plan for this project. What standards and controls would you apply to the above activities?
 
I would recommend the following standards and controls for the quality plan for testing, integration and debugging:
 
For testing to use the IEEE 1012-2004 standard for software verification and validation plans and to use the IEEE 829-2008 – standard for software and system test documentation to ensure the testing is following a good test plan that has been well documented. Furthermore for the whole of the project i would recommend the use of the IEEE draft standard for Software and Systems Engineering which includes software testing although it is a draft standard some procedures given can be followed to ensure the quality of the project.
 
Ensure software tester, software developer, project manager and end user are all involved in testing, integration and debugging so that the identification and the correction of gaps, errors and bugs is done as soon as possible and to ensure the system matches the desired requirements therefore ensuring the quality of the project.
 
Use various different types of testing to identify issues. From manual to automated testing, to using the different types of testing methods, to using functional testing like unit testing and the use of non-functional testing like usability testing. Furthermore ensure the use of traceability matrix to trace the requirements during the SDLC, so that each requirement is connected to a test case therefore making sure the software is developed according to the mentioned requirements.
 
There are many more controls that can be placed and standards that can be followed to ensure the quality of the testing, integration and debugging of the project.
 
References:
 
Griffith, M. (2013) Project Management: Estimation. Available: http://www.moltovivace.co.uk/pm-ug/ls04.pdf.  Accessed (25th March 2013).
 
Pressman, R.S. and adapted by Ince, D. (2000) Software Engineering: A Practitioner’s Approach, 5th edn (European adaption), Maidenhead, McGraw-Hill.
 
Tutorialspoint. (2000). Software Testing Quickguide. Available: http://www.tutorialspoint.com/software_testing/software_testing_quick_guide.htm. Last accessed 8th April 2013.

Code Complexity

Compare the complexities of the two pieces of code A & B using these two metrics LOC and cyclomatic-complexity. What conclusions can you draw about the relative complexity of the code?

Code A

Code B

int i = 1;while(i < =5){

playACard(i);

if (playerHasWon(i))

break;

i++

}

int j = 0;int i = 2;

j = i;

j = j + i;

j++;

System.out.println (j);

System.out.println

Code A and B both have the same amount of LOC which is 7 according to the LOC metric which counts the physical Lines Of Code.
Code A has a cyclometric-complexity of 3 (1 for if, 1 for while loop and 1 for the whole method), while code B has a complexity of 1 (1 for the method). Code A is more complex than code B according to the cyclomatic-complexity metric as code A has a while loop and an if statement while code B is linear.
Reference:
Cole, R. (2007) Cyclomatic Complexity and Unit Tests. [online] Available at: http://www.rkcole.com/articles/other/CodeMetrics-CCN.html [Accessed: 15 Apr 2013].
En.wikipedia.org (1976) Cyclomatic complexity – Wikipedia, the free encyclopedia. [online] Available at: http://en.wikipedia.org/wiki/Cyclomatic_complexity [Accessed: 15 Apr 2013].
En.wikipedia.org (2012) Source lines of code – Wikipedia, the free encyclopedia. [online] Available at: http://en.wikipedia.org/wiki/Source_lines_of_code [Accessed: 15 Apr 2013]

Identifying the risks

The most important risks that a project manager should be concerned about and should monitor are risks that affect the project staff, project cost, requirements and quality of the project.

Project managers should monitor risks to project staff, as the staff keep the project from failing and are key to the success and completion of the project. Teamwork difficulties, lack of productivity and distractions are risks that stem from project staff, so monitoring these risks and other risks to the staff will help ensure the project is on track and its quality isn’t affected.

Risk to project cost should also be monitored to ensure the cost of the project does not spiral out of control. Since all projects have a specific budget, project managers need to keep the project cost from going over its budget. This is where monitoring risks to project cost comes in to keep the project within budget.

Risks to the requirements of the project should also be monitored by project managers. If the project does not meet the requirements given by the client, the project would have failed. So keeping the project in check with it requirements means monitoring and controlling risks to these requirements.

Finally the risks to the quality of the project should be monitored and controlled to ensure the final product of the project is of a high standard. Not monitoring the risks to the quality of the project could lead to a poor product, scheduling and management. This is in turn could affect company reputation and revenue.

System Failure LAS case study

Large software systems are a combination of complex socio-technical systems when things go wrong there are tragic consequences that result in the loss of livelihood and lives.

The London ambulance service software failure is one such example, the LAS computerised dispatch system project spanned 5 years (1987-1992). The project involved the changing from the manual dispatch system to a more efficient and computerised system. Two attempts were made to create this project, the first in 1987-1990 it failed after putting £7.5 million into the project. The second failed 9 days after the system was launched which lead to the loss of lives and financial resources.

Case study: https://www.cs.kent.ac.uk/teaching/09/modules/CO/8/86/rdl/CaseStudies/Reports/reportLondonAmbulanceS.pdf

With the benefit of hindsight how could the shortcomings highlighted in the case study been avoided from a project management perspective:

There were known management problems within the LAS during the commencement of the CAD system. There was a lack of trust and an unhealthy relationship between staff and management of LAS on top of that the LAS was restructured which led to a 20% reduction of its managers. To ensure the success of the project, the management of LAS needed to work well and in cohesion with their staff, in project management having a good manager or managers can make or break a project. Having a good relationship between management and staff ensures a good working environment. It helps maintain communication and keeps both management and the staff clear on their objectives. The failure to communicate who was managing the project and what responsibilities some staff had led to the absence of control from the top and failure to manage those lower down. From a project management perspective there was poor change control, the LAS should have stopped the restructuring of management especially on a vital project like this. It would have kept disruption and confusion to a minimum.

There were preconditions on the CAD contract that were difficult to meet for a project of this size. LAS gave a non-negotiable date that gave only 6 months to the contractor to complete, it also set a limit of £1.5 million to be spent on the project. Due to the low budget the selection team chose a small software house that had no prior experience in creating such systems. The LAS should have done an estimation of the project prior to creating the contract so as to know the rough time and cost it would take to create the system. This would have helped in giving the right amount of time and money towards the project and it would have helped management understand the complexity of the system.

Key players/users of the system were not consulted. LAS did not follow the UK government project management methodology and their staff did not have prior experience with it. LAS should have consulted its key users and players of the system, the ambulance crew could have helped with the system specification and design. The system could have been tailored to meet their requirements, as they would need it the most. In project management having a methodology and following it, is key to the success of the project. LAS should have used a methodology that they and the contractor were familiar with, it would have helped to keep the project in check and would have helped staff understand their roles.

There was inadequate training for LAS staff, training was done 2 days before the system implementation date. This system is vital for the LAS to do their job which is to save lives. LAS should have spent more time on training its members of staff, if they had done an estimation and a risk assessment before hand they would have realised the importance of training. Any changes made to the system design, should have been relayed to the staff quickly and training should have been done for the changes. There should have been more time spent on testing the system with the staff, a mock test exercise could have been done after training to ensure the staff are capable in using the system.

Testing of the CAD system was minimum, some function testing was performed however the most important testing for this kind of system, integration testing was not. Testing is needed to ensure the system is working and is meeting its requirements. The failure of not having the correct requirements and failure to follow the project methodology thoroughly led to inadequate testing of the system. Testing and the implementation phase with software projects is the most crucial area to get done right. Testing helps identify bugs and errors, inadequate testing leads to problems during implementation. Again if they had done a risk assessment and an estimation they would have known the amount of time it would take to test this system and the risks of not testing.

The factors identified above led to the failure of the CAD system when it was implemented. Software was incomplete and failed to meet the needs of its users. From a project management perspective this shortcoming could have been avoided if

  • the project was planned properly
  • the right people were working on the project
  • they followed or done an estimation of cost and time for a project of this size
  • they done a risk assessment or had done and followed it
  • they communicated and involved their stakeholders and clients
  • they followed the methodology or changed it to one they have used before
A Study by Curtis et al (1988) identified 3 main factors to the failure of large complex systems, these factors affected the LAS CAD system too. There was a thin spread of application domain knowledge, fluctuating and conflicting requirements and breakdown of communication,coordination all of which led to the failure of the CAD system.
References:
Curtis, B. et al. (1988) A Field Study of the Software Design Process for Large Systems. Communications of the ACM, 31 p.1268 – 1287. Available at: http://cs.njit.edu/~kirova/BC-SDP.pdf [Accessed: 11th April 2013].
Moltovivace (2013) IM3045 Project Management. [online] Available at: http://www.moltovivace.co.uk/pm-ug/ls01.pdf [Accessed: 11th April 2013]
UCL (2000) Case Study London Ambulance Service CAD System. [online] Available at: http://www0.cs.ucl.ac.uk/staff/A.Finkelstein/advmsc/3.pdf [Accessed: 11th April 2013].