Welcome to the second lecture on the project team builder.
In this session, you will see scope management in practice,
as well as value analysis with the help of the PTB simulator.
We'll use the medium radar development project
by clicking on open/usecases/medium/mediumradardevelopment.scn.
This scenario is more complex.
So far, the project goals have been
defined in terms of project cost and project duration.
The third important goal,
which was not previously present,
deals with the performance of the system delivered by the project or the project value.
Each project can have any number of
quality requirements related to the value of the project provides.
This project has three quality requirements,
the range of the radar,
its quality, and its reliability.
Each quality requirement has a formula and a weight.
The weight defines the importance of the quality requirement on a scale from one to 10.
Each quality requirement has the best mode to maximize or to minimize its value,
as well as a range of acceptable values.
The requirement evaluation is calculated
based on the modes selected for the project tasks.
Each parameter in the formula is set by selecting a mode of a project task.
Each quality requirement received a score between zero and
100 according to how well the requirement is satisfied.
The weighted average of these scores determines the project value,
also measured between zero and 100.
You can see this value on the top right-hand corner.
The success of the project will be determined according to the three dimensions,
project duration, project cost, and the value.
A source of uncertainty is the duration of tasks.
Click on the task system engineering.
For the currently selected mode, small team,
the duration will be between five periods and 10 periods,
with the most likely duration of seven,
while the project again displays the most likely duration,
which is used for the estimated project duration as well.
This is not necessarily going to be the actual duration of the task.
The actual duration is randomly generated between the optimistic and pessimistic values.
If the project is being executed,
you should pay attention to task finishing before or after the expected duration.
In such case, you might consider corrective actions
in terms of resources and the scheduling of other tasks.
Let's look at the resource chart for engineers,
along with the resource information.
In this project, the resources have a show up probability of less than 100 percent.
This means that as the project is running,
some resource units might not show up when needed.
You should consider assigning more resources than your plan actually
requires to create the resource buffer and protect the project from this risk.
If you don't have sufficient resources,
you won't be able to advance that time.
There are a few options for solving this problem.
If a task that required the missing resources have not yet started,
you can postpone them or sometimes change the mode of
operation to one that require less of the missing resource.
However, if they've already started,
one of the tasks being executed must be split.
Splitting a task means that the task is paused for one period.
Splitting typically has an associated cost.
To split a task, click on the "Gantt" button and on the task you want to split.
Then, enter the split at a time when the split
starts and the restart time when the split ends.
The current project value is 76.67.
Let's see how you can improve it.
Click on the "Quality requirements" button.
The current range is about 11 miles,
which gets a score of 50 out of 100 since the requirement is 12 months.
The range is defined by a formula that includes the quality parameters TP, RS, and AG.
Move the mouse over the formula to see which tasks affect the evaluation.
You can see that if, for example,
you want to change the value of TP or transmitter power,
then you have to look at the task transmitter design.
Double-click on that task.
In the currently selected mode,
reengineer, TP gets a value of 50.
Change the mode to new design.
So the TP gets a value of 100.
Now click again on quality requirements.
Because the value of TP doubled from 50 to 100,
the range is no more than 13 miles as opposed to the previous value of 11 miles.
This exceeds the requirement of 12 miles.
You get a perfect score of 100 for the range.
This also increases the project value from 71 to about 88.
Notice, however, that this didn't come for free.
Now the task transmitter design will take nine periods.
It became critical task and will caused the entire project to be late.
This probably wasn't a very good decision to make.
However, it's an example of the tradeoff between cost duration
in value that's at the basis of project management-related decisions.
More points to consider.
One, tradeoffs between cost duration and value when creating a plan for the project.
Two, reducing the resource violation risk by buffering or having
more resources than actually necessary if the resource type has a low show up of ability.
Three, releasing excess resources to reduce the ideal resource cost.
Four, identifying the critical path and paying attention to the critical tasks.
We will learn more about this in the next units.
And five, verifying that the future cash flows does not run negative.
Avy ShtubProfessor
