Week 9. Project management

9.1 Manage Risks / Inherent Risk Factors

Inherent risks are those that exist based on the general characteristics of the project. These are risks that can appear irregardless of the specific nature of the project. The following checklist can be used to determine whether there are inherent risks on your project that you have not considered yet.

This table identifies characteristics that may imply risk, as well as criteria for knowing if it is high- risk and low-risk. Depending on where your project characteristics fall, you can evaluate whether your risk is high, medium or low. (Medium risks fall in between the extremes.)

Characteristic High Risk Low Risk Total effort hours Large project > 2500 hours Small project < 250 hours Duration Longer than 12 months Less than 3 months Team size Over 25 members Fewer than 5 Number of clients or client More than three One organizations Project scope / deliverables Poorly defined Well defined Business benefit Not clear (should not start the Well defined project) Project team and client business Neither the project team nor the Both the project team and the client knowledge client have solid business knowledgehave solid business knowledge Requirements Very complex, hard for client to Easy for client to define define Dependency on other projects or Dependent on three or more outsideNo more than one dependency on an outside teams projects or teams outside project or team Project Sponsorship Unknown (should not start the Identified and enthusiastic project) Client commitment Unknown, passive Passionate Changes required to existing Large amount of change Little change procedures, processes and policies Organization structures Large amount of change Little or no change Project manager experience Little experience on similar projects Similar experience on multiple projects Physical location of team Team is dispersed at several sites Team is located together Use of formal methodology No formal methods or processes Standard methods in use Technology New technology is being used for No new technology required critical components Response time Very short response times are Normal response time is acceptable critical Data quality Data is of poor quality Data is of good quality Vendor partnership Have not worked with the vendor Have a good relationship with the before vendor

Strategies for the Risk Response Once risks have been identified, there are a number of options that the project manager might consider for responses.

 Leave it. In this approach, the project manager looks at the risk and decides to do nothing. This can happen for one of three reasons. The project manager may decide that the potential impact of the risk on the project is not substantial enough to require a risk response. This would typically be the case for low level risks and many medium level risks. The project manager may feel that the risk should be managed, but that the negative impact of the risk is not worth the cost and effort required to manage the risk. There may not be any reasonable and practical activities available to manage the risk. This is different from the prior reason where the cost was more than the benefit. In this case, there are is no practical way to manage the risk, even if the risk has been identified as high. For instance, it is possible that there is a risk of your sponsor leaving and a new sponsor canceling the project. In fact, you may know that the sponsor is up for a promotion and that this scenario has some possibility of occurring. However, you may not be in a position to do much about it as long as the current sponsor is in place, and you may just need to leave it and see how events play out.  Monitor the risk. In this case, the project manager does not proactively manage the risk, but monitors it to see whether it is more or less likely to occur as time goes on. If it looks more likely to occur, the team must formulate a different response at a later time. This approach can work for serious risks that are not likely to occur. Rather than put a plan in place immediately, the project manager creates a plan only if it looks likely that the risk will occur. The advantage is that scarce resources are expended only on those risks that are likely to occur. The disadvantage is that the delay in addressing the risk might make it less likely that the risk can be successfully managed in the future. This is also a good approach if you have identified a risk that should be managed, but the risk event is far off in the future. For instance, if your risk event is nine months in the future, it may not make sense to spend resources to manage the risk at this time. A better approach might be to monitor the risk on a monthly basis. It is possible that over time the risk will go away because of other circumstances. However, if it does not go away, the team will still need to manage the risk in the coming months.  Avoid the risk. Avoiding the risk means that the condition that is causing the problem is eliminated. For instance, if a part of the project has high risk associated with it, the whole part of the project is eliminated. For instance, risks associated with a particular vendor might be avoided if another vendor is used instead. This is a very effective way to eliminate risks but obviously can be used only in certain unique circumstances. In another example, you may have a project risk associated with implementing a solution in multiple locations. Once the risk is identified, the sponsor may change the scope of the project to only implement in one location. In this way, the risk of implementing at multiple locations has been avoided.  Move the risk. In some instances, the responsibility for managing a risk can be removed from the project by assigning the risk to another entity or third party. For instance, outsourcing a function to a third party might eliminate that risk for the project team. The third party might have particular expertise that allows them to do the work without the risk. Even if the risk is still present, it now is up to another party to resolve. Another example of moving the risk is buying insurance. In a simple example, you may have a very fragile and valuable part that needs to be shipped to your project team. There is some risk that the material will be damaged. You might move the financial risk by purchasing insurance on the shipment. Of course, if the shipment is damaged, you may still lose time waiting for a replacement part to be shipped. However, you no longer have the financial risk. In exchange for an insurance payment, the insurer now has the financial risk.  Mitigate the risk. In most cases, this is the approach to take. Mitigating the risk means that you put in place a set of proactive steps to ensure that the risk does not occur. Another purpose of mitigation is to ensure that if the risk occurs, the negative impact of the risk is minimized. For the purposes of the TenStep Project Management Process, it is generally assumed that Risk Management Plans are put in place to mitigate the risk.

Manage Risk / Deliverables

Major Project Risks

Ref Risk Description Owner Probability Impact Priority No. Cost Schedule Quality

Risks Mitigating Plan

Ref Risk Description Ways of Mitigation No.

9.2. Procurement Management

Procurement means acquiring goods and/or services from an outside source. In respect to Information Services very often the following goods/ services are purchased:  Hardware  Software  Vendor Services for installation  Third Party consulting services, including outsourcing for the development  Vendor maintenance services  Training Services

To organize purchasing special documents should be created and signed by both sides:  Contract – contains all legal term  Technical Specification – for goods (software, hardware, other)  Statement Of Work (SOW) – for services 9.3. Communication Management

That is extremely important task of Project Manager. Do not let it go without planning

Communication Plan Audience Content Medium Frequency/ Communication Who is for Timing Deliverables responsible Delivery Mini- Project Lectures As Project T.O. Project Management Team scheduled Management Teams Methodology meetings Documentation

Mini- Technical Lectures As Technical T.O. Project Solutions scheduled Documentation Teams

9.4. Scope Management

Project scope (In scope and Out of scope) is defined initially in a Project Charter document. During the life cycle, scope changes requests can occur, even before first release has taken place. Important recommendations: - Create and support formal procedure of changes requests - Create and maintain change requests log - Have a project sponsor approval to implement changes - Inform team members about a discipline of changes request - Identify the moment when all the changes must be frozen during the development time - Reflect changes in WBS, project schedule and other supporting documentation.

9.5. Project time management

Planning stage The main processes involved in project time management include: - Activity definition, or tasks presented as WBS - Activity sequencing, which involves identifying and documenting the relationships between tasks - Activity duration estimates - Schedule development

Activity definition is based on the project scope. The project team should understand in details all the works to be done. It is helpful to construct WBS basing on project development life cycle. Activity sequencing involves identifying dependencies existing between different tasks. Dependencies result in tasks chaining that then will be converted into Project Network Diagram. The diagram is to display logical relationships among, or sequencing of, project activities. Basing on the diagram PM could estimate so called Critical Path (see below). To make the diagram more understandable there is no need in including all the detailed tasks – it might be enough to have summary tasks only. Or, make a few diagrams.

Activity duration estimates is the most tricky part of time management. PM needs experienced developers to provide estimates. However the estimates should be revised to see if they are realistic. Deviations might happen to both directions – asking too much or too little of time. Some recommendations about how to mitigate the risks of severe estimating mistakes: - Obtain both optimistic and pessimistic estimations. If possible have estimation of a similar task from the project once completed. Take into account people skills - Do not allow tasks with duration longer than 10 working days - Consider calendar time, not a pure working hours, especially if the team members are multitasked. Duration for the schedule is not the same as working hours to evaluate the cost - Allow buffer time but make it reasonable. Developers have a tendency to add buffer time to each particular task estimate, what might finally increase total time greatly. Instead of each task, have a buffer time for the whole project

Schedule Development - Use the tools like MS Project

Implementation Stage

The main process is: Schedule Control

It means making changes in the schedule to keep it accurate. PM should reflect the reality in tasks implementation including WBS. One important recommendation about changes – corrections should keep history of things. Particularly, if the task duration turned out to be longer than initially estimated, do not simply prolong the duration. Apparently, there should be more detailed WBS, with some more tasks overlooked at the beginning. Consider the first one as a summary task and add detailed tasks under it providing new estimation.

Project Network Diagram and Critical Path

When planning is done we have Project Plan (Project Schedule – both terms are in use) showing the tasks, their order and time for implementation with resources planned for it. Development stage brings up the most difficult task of project management – how to meet the plan, and particularly the time schedule. The circumstances around us are always frustrating, so always expect the problems. First of all from the very beginning try to be realistic answering the question “When the project will be finished”? In project management methodology the “Critical Path” length is to show the shortest time to complete the project.

Critical Path

To build the critical path we do the following: 1. Consider every task from your project plan as a node. Each node has its weight – the time for the development 2. Link the nodes to show their sequence. If some activity is supposed to be done in parallel, create the parallel chain 3. Set of chains must have one entry point (the project start) and one point out (the project finished) 4. In the diagram find out the longest way from start to finish and calculate the total time. 5. The longest way is Critical Path. The total time of critical path is the shortest time the project could be completed.

Example: Price Lists Online Support – Development Stage

Nodes and Weights A – Entity Classes Design, 5 days B – Classes Relationships, 5 days C – View and Controller Design, 4 days D – Class Diagram Completed, 5 days F – Programming, 4 days G – Documentation, 4 days H – Testing Plan, 12 days

4 G 5 5 4 5 4

Start A B C D F Finish

12

H Possible ways: Start – A – B – C – D – F – Finish, 23 days Start – A – B – C – D – G – Finish, 23 days Start – A – B – C – D – H – Finish, 31 days – This is Critical Path. The shortest time to complete this stage is 31 days 9.6. Quality Management

Project Management activity has some specific points at the stage when the project has been moved to testing. Usually the length of testing is defined basing on the experience. First of all PM should take into account iterating nature of testing. It creates unpredictable development environment when each developer may be urgently returned to his previous activity. For this reason it is better not to make heavy plans for the period of testing. Reasonable estimation of time available for other than defects correcting activity is not more than 50% for the first half of the testing period and 75% for the second half in average.

Apart testing quality management includes:  Control of Documentation  Control of Processes through Release Management

9.7 How to overcome practical problems – The Art of Making Priorities

Project Manager has at least three possible techniques to overcome the problems that may impact the project success. There is no formula, and every time the decision is to be made by a Project Manager basing on his experience and factual situation. The techniques for consideration are shown below.

Scope management

In the case if no other ways exist, PM is to reconsider the project scope trying to identify critical functions to implement and less important functions. Usually a project scope allows such segregation. When it is done, reconsider the project plan to concentrate available resources on critical tasks first of all, delaying less important. They could be implemented later, for example when the critical tasks are moved for testing. Usually Main Success Scenarios present critical tasks. Stop doing with extensions for a while, develop critical tasks and move them for testing. After this developers can continue with extensions.

Other example of scope management is the choice between mandatory and “nice to have” tasks. Again usually the project has some of “nice to have” kind of tasks. PM might be in need to postpone them essentially or even to exclude them completely.

Resource Management

People are most critical and expensive resources in software development projects. PM must be extremely attentive to the development team creating. Team Leader must be experienced in major technologies that are supposed to use. Some education “on the go” always exists but it must not concern the technology principals. If it is not possible to meet this requirement it is better to start with Pilot Project. Pilot Project scope is to comprise major functions and technologies. Its goal is actually “the proof of concept”, either about business needs, or about technological solutions, or both. Pilot Project Development gives a good chance to build the team.

PM must be always ready that some of existing team members quit the project. The best way of being ready is to follow the formalities, never mind how boring they are. The formalities concern the development methodology and standards and the technical documentation. If it is MVC pattern approved for the development, all the design solutions must meet MVC requirements. Design alternatives and the decisions must be described and documented. All classes and operations must be documented. Source code must be well commented.

For complicated projects another precaution is that Team Leader must have the assistant – a person who is to participate in all technical discussions and keep all technical ideas in his head. That may help if Team Leader quits the project.

Keep in mind that every new person included first of all causes the delaying. For this reason it might not be helpful at all to include more people into the team when the essential part of job is done.

Avoid overloading one person and not enough loading the other. Both situations are bad for the team spirit. Give to each person a chance to learn new things or to improve his skills.