Десять методов оценки  работ проекта  (часть 1 из 2)

Оценка работ проекта  является ключевым элементом планирования проектов. Последующие методы могут использоваться на проектном уровне, уровне проектной операции,  для любых других работ поддерживающих работу  проекта или между проектами. Например, экспертное заключение может быть использовано, как руководство для оценки  всего проекта или  конкретной работы проекта.

Оценки Высокого уровня.  Оценки Высокого уровня, как правило, называют методами "сверху вниз". Такие методы включают в себя предшествующей истории, аналогии и пропорциональные соотношения. Оценки, основанные на более тщательной разбивке работ, называют методами  "снизу вверх". Техника Структурной разбивки работ (WBS)  например, это метод "снизу вверх".

Оценки "Сверху вниз", как правило, быстрее и проще, так как вы оцениваете работы на уровне проекта в целом. Они также могут быть менее точными.
 

-   Предыдущая История. Если организация ведет учет фактических затраченных усилий в виде человеко- часов и стоимости  предыдущих проектов, вы можете иметь информацию, которая поможет вам оценить подобные, но новые работы проекта или весь проект. В этом методе характеристики предшествующей работы, наряду с израсходованными чел\ часами и материальными затратами, сохраняются, так что информация может быть использована для будущих проектов.

-   Аналогия. Даже если Вы не храните фактические затраченные усилия в  чел\часах от предыдущих проектов, вы все равно можете быть в состоянии использовать работы предыдущих проектов. Аналогия означает, что вы находите подобные проекты в прошлом, даже если команда проекта не собрала фактические усилия отработанных часов. Например, давайте предположим, что длительность проекта была рассчитана в шесть месяцев и 2000 чел\часов. Если проект на самом деле был завершен через шесть месяцев, то велика вероятность, что проект также потребовал  приблизительно 2000 часов работы (Под часом работ мы понимаем чел\час).

-  Пропорция. Пропорция похожа на  аналогию за исключением того, что у вас есть некоторая основа для сравнения работы, которая имеет похожие характеристики, но на большем или меньшем масштабе. Например, вы можете обнаружить, что усилия в часах, требуемое для выполнения переезда офиса в новый офис  были 500 часов, и что один из главных критериев для определения требуемых усилий - это количество людей в офисе. Если будет в два раза больше людей в другом офисе, который требуется переместить в новый офис, вы можете заключить, что для выполнения  работ  может понадобиться   1000 часов.

-  Экспертная Оценка. Во многих случаях вам может понадобиться пойти к внутреннему или внешнему эксперту, чтобы получить помощь в оценке работы. Например, если это первый раз, когда вы использовали новые технологии, вам может понадобиться помощь постороннего исследовательской фирмы, чтобы получить оценочную информацию. В большинстве своем, эти оценки основаны на опыте других предприятий данной отрасли. Вы также можете иметь внутренних экспертов, которые могут помочь. Хотя это может быть и ваш первый опыт по оценке данной работы, возможно кто-нибудь уже делал это много, много  раз.

-  Делфи. Метод Делфи похож на экспертную оценку, за исключением того, что используется несколько экспертов и нужно попытаться достичь консенсуса между их оценками

Если возможно, вы должны использовать несколько методов для оценки проекта, особенно если вы используете быстрые "сверху вниз" методы. У вас будет больше уверенности в вашей оценке, если вы используете две или более метода,  с целью получения совпадающих результатов.

..............................................................................................................

Десять методов оценки Работ Проектов
(часть 2 из 2)

Оценка является одной из самых важных частей планирования проекта.  Мы уже  исследовали пять методов оценки работ в чел\ часах, продолжительности и затрат на проект. Вот остальные пять.

•   Структура разбивки работ. Work Breakdown Structure. Структура разбивки работ позволяет более легко оценить  работу. Вы можете посмотреть на большой кусок работы и с трудом оценить усилия необходимые для его выполнения. Однако, если работа разбивается на более мелкие куски, отдельные компоненты будет легче оценить. Когда вы оценили все фрагменты, сложите их все вместе и получите  требуемые усилия для выполнения. Если у вас есть время, чтобы создать хорошую WBS, вы, как правило, в конечном итоге, имеете  хорошую величину оценки требуемых усилий.

• Программная и ревизионная оценка. PERT.   PERT является методикой оценки стоимости, которая  использует средневзвешенное значение трех чисел как окончательную оценку. Используя технику PERT, если вы  оцениваете усилия, необходимые для завершения работы, вы должны начать с трех оценок - самый пессимистический (P) случай, когда все идет не так, самый оптимистичный (O) случай, когда все идет хорошо и (M) в случае  нормальных проблем и возможностей. Итоговая оценка PERT (О + 4М + Р) / 6. Например, если оценка М  10 часов, оптимистическая  оценка О 6 часов и пессимистическим оценка Р 26 часов. Оценка PERT является (6 + 4 (10) + 26) / 6.Ответ 72/6 или 12 часов. Обратите внимание, что цифра была сдвинулась немного в сторону пессимистической оценки, но не намного, так как результат все еще тяготеет  к наиболее вероятного значения М.

• Параметрическое моделирование.  В этой технике  должен существовать шаблон оценки куска работы, что позволит использовать такой алгоритм  для производства общей оценки. Например, если вы знаете, что вы можете построить одну милю однополосного  шоссе за миллион рублей, вы должны быть в состоянии легко сделать оценку для десяти милей  четырех полосного шоссе (40 миллионов рублей).

• Оценка фиксированного времени проекта. Timeboxing. Это способ  оценки в пределах фиксированного графика, или бюджета, или объема работ. Обычно, когда вы применяете метод timebox, вы предполагаете, что проект должен быть завершен к определенному сроку. Затем вы должны сосредоточиться на аспектах определения стоимости и объема в условиях  тройных ограничений, так что бы дата timebox, завершения работ, должна быть соблюдена

• Функциональные баллы (ИТ проекты). Function Points (IT development projects).  Многие отрасли промышленности имеют специализированные модели оценки для своих проектов. Некоторые ИТ организации  используют Функциональные баллы как средство обеспечения достоверной оценки работ, необходимых для завершения проекта по разработке проекта системы ИТ. Функциональные баллы обеспечивают механизм для определения относительной сложности разрабатываемого ИТ приложения. Сложность может быть выражена как количество Функциональных баллов. Таким образом, ИТ приложение с 1000 Функциональными баллами, как правило, в десять раз больше и сложнее, чем ИТ приложение с 100 Функциональными баллами

Мы рассмотрели десять разных оценочных методов. Каждый метод не будет работать в любой ситуации. Знание лучших методов оценки, позволит вам в каждой конкретной ситуации  обеспечить более точную окончательную оценку

.........................................

Six Steps to Create a Project Scorecard

Project teams should know if they were successful or not. Sometimes there is a disagreement between the project team and the sponsor. This can always be the case when the criteria are subjective.

A better approach is to create a tactical project scorecard that lays out the metrics that validate project success. Then the discussion can become fact-based and not opinion. The six steps to create the project scorecard are as follows

The project scorecard is updated throughout the project so the team knows how they are tracking against their success criteria. When the project is done you can have a fact-based discussion on project success instead of a discussion based on perception.

.........................................

Managers don't need detailed training to actually manage projects. But they do need a high-level understanding of projects and their role in the project environment. Buy this two-hour e-class and start learning the basics immediately.　

Seek Project Approvals from the Right People

Once the project has been defined, the project manager should seek formal approval from the sponsor and appropriate management stakeholders. There are many ways to gain formal project approval. A little bit of planning is the key. For small projects, one signature from the main client or project sponsor is probably sufficient to show approval of the work to begin. This approval could also be via email confirmation. However, it should not be verbal.

For larger projects, ask your manager and the project sponsor to identify who should have explicit approval of the Project Charter, who should have implicit approval and who needs to get a copy for informational purposes only. In general, use the following approach as your starting point:

Identifying these three levels of approval will ensure that the right people review the Charter, the right people approve the Charter, and the others have a copy for their information.

Ten Steps to Estimate Effort on your Project

Estimating is one of the most important parts of the planning process. Effort hours (man hours) must be estimated first, before duration and cost estimates can be prepared. Use the following ten steps to estimate effort hours.

1. Determine how accurate your estimate needs to be

Typically, the more accurate the estimate, the more detail you need to understand about the project, and perhaps the more time that is needed. If you are asked for a rough order of magnitude (ROM) estimate (-25% - +75%), you might be able to complete the work quickly, at a high level, and with a minimum amount of detail. On the other hand, if you must provide an accurate estimate within 10%, you need to spend more time and understand the work at a lower level of detail.

2. Create the initial estimate of effort hours

Estimate the work of the project using one or more estimating techniques (analogy, prior history, PERT, modeling, etc.). (These techniques will be described in a separate Tips email).

3. (optional) Factor the effort hours based on the resources assigned

Your estimates are probably based on the effort it will take an average resource to do the work (or perhaps the estimates are based on the effort it would take if you did the work). Sometimes you also have knowledge of the exact resource or the type of resource that will be assigned. If you do, you may want to factor the estimate up or down based on that resource.

4. Add specialist resource hours

Make sure you have included hours for part-time and specialty resources. This could include freelance people, training specialists, administrative help, etc. These are people that may not be obvious at first, but you may need them for special activities.　 Because they are typically in project support roles, you may have forgotten to include their activities in the original Work Breakdown Structure.

5. (optional) Add rework time

In a perfect world, all project deliverables would be correct the first time. Rework is the result of flaws in your quality management process. It means that a deliverable that you thought was complete turns out to need more work. Some projects add in effort hours for rework, although this should be minimized.

6. Add project management time

Project management takes effort. A rule of thumb is to add 15% of the effort hours for project management. For instance, if a project estimate is 12,000 hours (7 - 8 people), then a full-time project manager (1800 hours) is needed.

7. Add contingency hours

Contingency is used to reflect the uncertainty or risk associated with the estimate. If you are asked to estimate work that is not well defined, you may add 50%, 75% or more to reflect the uncertainty. If the estimate was required on short notice, a large contingency may be required. Even if you have time to create a reasonably accurate estimate, your contingency may still be 10-25%. If you do not add a contingency amount, it would mean that you are 100% confident in your estimate. This may be the case if similar types of projects have been done before.

8. Calculate the total effort

Add up the estimates for all the work components described above.

9. Review and adjust as necessary

Sometimes when you add up all the components, the estimate seems obviously high or low. If your estimate does not look right, go back and make adjustments to your estimating assumptions to better reflect reality.

10. Document all assumptions

You will never know all the details of a project for certain. Therefore, it is important to document all the assumptions you are making along with the estimate.

....

Project Managers Have Process and People Responsibilities

What does it take for the project to be a success? If the project has any kind of complexity you need a good project manager. To be successful, a project manager should have great skills for managing the project management processes, and for managing the people on the project.

The project management processes include:

Remember, this does not mean that the project manager physically does all of the work, but he must make sure it happens. If the project has issues or scope creep, or faces risks, or if expectations are not set correctly, the project manager is the person held accountable.

To manage the project management processes, a person should be well-organized, have great follow-up skills, be process-oriented, be able to multi-task, have a logical thought process, be able to determine root causes, have good analytical ability, be a good estimator and budget manager and have good self-discipline.

In addition to process skills, a project manager must have good people management skills. This includes:

The project manager is responsible for managing the staff on the project. This is usually a shared responsibility with the team member's functional manager.

....................................

How Many Projects Can One Project Manager Manage?

Sounds like a riddle. Many project managers wonder how many projects can be effectively managed at one time. The answer, perhaps surprisingly, starts with some simple math. First, we make an assumption that project management typically accounts for 15% of a project’s effort hours. In other words, if a project is estimated to take 1,000 hours of effort, you should allocate 150 hours for project management. Some companies allocate 10% of hours to project management, while others allocate up to 20%, but 15% is a reasonable rule of thumb.

Once we have that basic assumption, you can look at the sizes of projects you need to manage. You can calculate the total number of project management hours and the period of time when the hours are spread. You apply your project management percentage and then you should be able to determine how the number of projects that one project manager can manage.

The best way to envision this is to look at some examples.

The project management time is calculated at 1,800 hours (12,000 * .15). Since the project is one year, there is a need for a full-time project manager for the year.

In this case, you will need 900 hours of project management time (6,000 * .15). Since the project is spread over year, the project will need less than 20 hours of project management time per week. Therefore, it is possible for a project manager to manage two projects of this size over a one-year timeframe.

In this case, Project C will need 12+ hours per week (for 12 weeks), Project D will need 8+ hours per week (for 35 weeks) and Project E will need 12+ hours per week (for 8 weeks). One project manager could manage all three projects since the total project management effort is around 32 hours per week.

Next we can get a little more sophisticated. As you know, project management time does not occur in a straight average number of hours per week. There will be some peaks and valleys of time requirements on each project. For example, the planning process needs a lot of project management time. A project manager could be full-time during planning and then require fewer project management hours as the project progresses. This could allow the project manager to start planning another project after the first project stabilizes. However, this is the overall staffing model you would use to determine whether a project manager has too many, too few, or just the right number of projects to manage.

　Five Things to Remember When Interviewing New Team Members

Once your project is planned, approved and ready to execute, a project team must be put together. In some cases, you need to hire for the positions. These could be employee hires or contractors. The interview process is important – even more so if the person will be a full-time employee. Here are a few simple rules to remember before your interview.

It is good if multiple members of your team are part of the interview process. In this case, there are two main formats. The first is the “revolving door”. You get the candidate in a room and bring in the interviewers one at a time. Similarly the candidate can move from office to office to speak one-on-one with the interviewers. This method gives everyone a chance to gain an independent opinion of the candidate from different perspectives and using different questions, but it does require a longer time commitment from the candidate.

The second format is the “Spanish Inquisition” (apologies to any readers from Spain). You get the interview team in one room with the candidate. This approach lets everyone hear the same story one time and is the most efficient use of the candidate’s time. One drawback is that it can be very intimidating. You need to go out of your way to maintain a friendly and casual atmosphere. Many people’s preference for a group interview is the Inquisition, since everyone hears the same story and it gives some indication of how well the candidate responds under some pressure.

Your company is relying on you to help ensure that qualified candidates are hired. This is an important job and should be taken seriously. Whether you interview one-on-one or in a group, make sure you ask thoughtful questions and listen carefully to the responses. Then, be prepared to provide honest feedback during the interview debriefing process.　 This increases the value you provide to the interview process and helps your company make good, long-term hires for the future.

....................................

Use These Two Techniques to Identify True Risks

Make Sure Your Risks Must Have Some Level of Uncertainty

If an event is identified as a risk, there has to be some level of uncertainty involved. In other words, if an event has a zero percent likelihood of occurring, it would not make sense to identify it as a risk. It is not even a low risk. It is not a risk at all. On the other hand, if an event is 100% certain to occur, it is also not a risk. It is not even a high risk. It is a fact. Sometimes these 100% events are also called constraints. A constraint is an event or limitation that impacts your project and must be planned around. For instance, you may not be able to get a resource you need until 30 days after the project starts. This is a constraint, not a risk. This constraint may cause a scheduling risk, but the constraint itself is not a risk.

A risk has some probability between 0% and 100% chance of occurring. When you are managing risks, be sure to focus on the risks and not on facts and non-events.

Distinguish Between Risks, Causes and Effects

There is a cause for every risk and an effect if the risk occurs. When the project risks are identified, make sure that the risk itself is noted and not the cause or effect of the risk. The cause is a situation that exists that sets up a potential risk. In general, the cause is a fact or a certainty for the project. On the other hand, the effect is the likely outcome if the risk occurs.

Look at the following example. Let's say that a project solution needs to be implemented in all of a company's worldwide locations, including those in developing countries. If the telecommunications lines are not upgraded on time, the solution will not be viable in those locations.

In the previous example, what is the risk?

When you are listing risks be sure to identify the risk itself - not the cause or the effect.

........................................

Look Behind and Ahead at Gate Reviews

At the completion of a major project milestone or phase, the team should take a short pause to make sure the project is on track and ready to proceed. This is a gate review and it includes taking a look behind to make sure all the things you have completed all the things you should have.

The backward look includes the following.　

Think about the purpose of a gate. You open the gate, step through and move forward. Similarly the most important part of a gate review is the forward look. You need to be sure you are ready to move forward on the project. The forward look includes the following.

Once you have validated that all of the prior work is complete and correct, plus you have validated the readiness to proceed, you should obtain a formal approval to move to the next phase. In other words, the phase “gate” is now open to enter and pass through.

....................................

Practice Ten Components of Integrated Change Control

Change on a project should result in executing a change control process. However, it may not be so tidy. A change in one aspect of the project can lead to changes in other areas as well. For example a scope change request may lead to an increase schedule and budget. The request might impact the resources that are needed on the project and it might effect a vendor contract. The project manager needs to understand the nature of the change and how it might impact all other aspects of the project as well.

That is one of the main purposes of Integrated Change Control, a high-level process that helps you understand the nature of change on your project and how to manage and control change more effectively. Integrated change control includes the following activities.

We often see specific processes for scope change management, but Integrated Change Control is a way to think about the nature of change on your project in a more holistic way.

.............................................

Use These Six Sections for a Staffing Management Plan

The Staffing Management Plan describes your overall approach for acquiring and managing human resources on your project. The types of information to include in this plan include:

Most projects do not need a Staffing Management Plan. However, if your project uses a lot of human resources, this Plan may be helpful for you to think about how you will acquire, develop and motivate the staff on your project. If it is helpful to you, create one.

....................................

.

Create a Work Breakdown Structure in Three Steps

The first major step in building a schedule (sometimes called a Project Plan) is to create a Work Breakdown Structure (WBS). This is a way to identify to work that is required to build the deliverables of the project. The WBS allows you to break the large project down into small enough steps that the work can be understood. The process for building the WBS is as follows

1. Identify the large “chunks of work” of the project

First determine the large chunks of work that must be completed for the entire project to be completed. When you start, it does not matter how you define the large chunks of work. For instance, a traditional breakdown might be "planning / analysis / build / implement", which lays out the project in a high-level timeline. The breakdown could also be by major deliverable such as "permits, pool, fence, landscaping". You can break down the work into whatever structure makes sense for your project.

2. Evaluate each lower element of the WBS

Check each component of the WBS to see if it meets the following two criteria.

If you understand the detailed work required to complete the component and if the estimated level of effort is smaller than the estimating threshold you do not need to break the component down further.

3. Continue to break down each component as needed

Work components that require more effort than the estimating threshold, or work components that you do not fully understand should be broken down further into smaller pieces of work. As you break the work down, you are ultimately going to create activities that are required to complete the deliverables. This is referred to as an "activity based WBS". The detailed activities from the WBS are what get carried forward to the schedule. 　　　

This process of breaking the work components into a lower level set of components should continue until all of the work components are represented as granular as necessary to ensure that no activities have estimated effort larger than the estimating threshold, and that you understand the work. This takes you to levels 3, 4, 5 etc. Rarely would you need to break the work down greater than five levels.　

Planning Components

There is one exception to this process. If your project is large and long, it is likely that you may not know enough to be able to break all of the work down to a discreet level. Work that takes place a long way in the future may have to be left at a higher level. These are known as planning components. In that case, you can leave the work components at the higher level until you get closer to execution (three months), at which time you will know enough to be able to break the work down at a more granular level.

When you are done with the process above, you will understand the work at the lowest levels of the WBS and the work will be smaller than your estimating thresholds. At that point the WBS is completed.

...................................................

Use Traceability to Ensure All Requirements are Met

Traceability refers to the ability to trace, or track, requirements throughout the lifecycle and into the final solution. Tracking requirements through the project ensures that all requirements are built into the design, all requirements are built into the solution, all requirements are tested and all requirements are implemented in the final solution. This is part of a structured lifecycle process.

Use a Traceability Matrix

The easiest way to create a link between your requirements and other development elements is by developing a Traceability Matrix. You could just number the requirements as "1", "2", "3", etc. However, you might want to build more sophistication into the numbering scheme. For example, you could give the requirements smarter names such as "TAB-001", "TAB-002", "DIS-001", "DIS-002", etc.

Tracking requirements can be done in a couple simple ways. One way, probably the simplest, is to just validate that each requirement is accounted for in each project phase. For instance, something like the following table might do.

The "X" in each box validates that each particular requirement was accounted for in each phase.

A more sophisticated example is shown below. In this case, the requirements are tracked through each project phase and the individual components are also identified.　

This tracking requires the team to keep more details as the requirements are proceeding through the lifecycle. However, it may be helpful to understand the details of the initial requirement, the design element, the component that contains the code for the requirement and the particular test case that ensured that the requirement worked correctly.

The key thing to remember about traceability is that it must be enforced throughout the lifecycle or else it doers not work. If the team assigns tracking numbers to the requirements, but the requirements are not tracked in subsequent phases, the whole tracking scheme will break down.