Why Managing Critical Path is Critical!

Practicing PMs should review their schedules on a regular basis to gauge if their project is on track or need some active management to correct any schedule deviation. If there is any deviation, there are a number of project management techniques that can be used to bring it back on schedule. This is where critical path method technique comes for the rescue!

The Project Management Body of Knowledge (PMBOK) defines the critical path method or more commonly termed critical path as “the sequence of schedule activities that determines the duration of the project.” Project managers can also apply the critical path methodology technique to “determine the amount of float on various logical network paths in the project schedule network to determine the minimum total project duration.”

Critical path method is a modeling technique and is commonly used with all forms of projects, including construction, aerospace and defense, software development, research projects, product development, engineering, among others. Any project with interdependent activities can apply this method of mathematical analysis

To identify a critical task is to construct a model of the project including the following:

• A work breakdown structure
• Estimating the time duration required for each activity
• And dependencies between the activities

What is a Critical Task?

A task in your project schedule becomes critical if:

• It has no slack
• It has a Must Start On or Must Finish On date constraint.
• It has an As Late As Possible constraint in a project scheduled from a start date.
• It has an As Soon As Possible constraint in a project scheduled from a finish date.
• It has a finish date that is the same as or beyond its deadline date.

Note that a task stops being critical when it’s marked as completed, because it then can no longer affect the completion of successor tasks or the project finish date

What is Fast-Tracking?

Fast tracking means that activities that are normally done in sequence are done partially in parallel by adjusting the resource availability upfront. For instance instead of waiting for entire design of your IT project to be completed, you consider starting a chunk of development/coding work in parallel. Fast-tracking at times involves risk that could lead to increased cost and some rework later. For example if the design changes at a later stage, development work done in parallel to design may lead to complete or major re-work! So Project Managers have to evaluate based on unique situation of their projects after careful consideration of trade off.

If you’re willing and able to spend more to accelerate the schedule, fast-tracking may be a viable option for you.

Crashing the project schedule

“Crashing” the schedule means to throw additional resources to the critical path without necessarily getting the highest level of efficiency.

For instance, let’s say one person was working on a ten-day activity on the critical path. If you were really hard pressed to shorten this timeframe, you might add a second resource to this activity. Additional resources may come from within the project team, or they may be loaned temporarily from outside the team so crashing usually always leads to some additional incremental cost to the project. Additionally you may also like to evaluate following techniques depending on your project situation;

• Schedule overtime.
• Shorten the duration or work on a task on the critical path.
• Change a task constraint to allow for more scheduling flexibility.
• Break a critical task into smaller tasks that can be worked on simultaneously by different resources.
• Revise task dependencies to allow more scheduling flexibility.

In conclusion, both Fast-Tracking and Crashing should be applied only on Critical Tasks on your project schedule, as if they are applied on non-critical tasks they won’t be much useful. Also note that Fast-Tracking is always considered first line of defense mostly because it does not increase your project cost.

Shyam Verma, PMP, ITIL

IT Project & Program Delivery Professional

LinkedIn:spverma. Twitter: Shammy11

This article is also available on blog site http://pmpower.wordpress.com

Evolving role of Enterprise PMO

In recent years, with general adoption of IT Governance practices, Enterprise Project Management has become more critical than ever before as it is widely recognized that a project co-exists with many other projects in the enterprise, or are part of one or more programs. While the initial mandate for PMOs was to only plan and track the existing set of projects and aimed for helping project professionals, envisaged more in the lines of functional department. However, given the strategic value of PMOs in today’s fast paced enterprises, they are not necessarily limited by that original stereotype.

So in that sense, PMOs today no longer exist as isolated function that directed only to the project managers and generated project reports periodically. Even though it is still the owner of setting the organization’s Project management methodology and prioritizes future and current projects against strategic business goals. The later has equally become more important given the pace of development and time to market pressures thereby area of more sought after value

The evolution: Over the years PMO functions have become significantly broad-based from just being the body of knowledge, training and reporting but also leading delivery accountability on critical initiatives. It has assumed and rightly being leveraged by several execution centric organizations as an integral part of delivery arm or business unit. Some time structurally organized horizontally and collaborating with several business verticals and corporate functions that are engaged in delivery of critical project and programs. In that role, it can and in some enterprises already performing the role of ‘delivery assurance’ continuously setting baselines and metrics of delivery efficiency as well as providing that crucial insight in to longer term strategic planning.

The Integrator: With its continuously evolving role, today it is much more aligned with not only with technical functions (R&D and technology Labs) within the organization but also business, HR and legal functions playing much-needed ‘integrator’ role with the bigger picture mandate. Based on the knowledge of past projects, baseline technical standards & over time potential improvements, it also provides the planning confidence to set the bar right for what is feasible against what is not for execution stage.

Value for top management: PMOs provide CIOs the structure needed to both standardize project management practices and methodologies for repeatable project processes as well as business value in identifying best suited program initiatives for implementation and funding viability for achieving organizations strategic intent. . Clearly today PMOs are more strategically valuable for business leaders and senior managers including the C level executives as much as it is with project professionals in day-to-day role as it advises and champions the business initiatives with best ROI on investment for the company.

Shyam Verma, PMP, ITIL

IT Project & Program Delivery Professional

LinkedIn:spverma. Twitter: Shammy11

This article is also available on blog site http://pmpower.wordpress.com

Calculating FTE Hours

Full-time equivalent (FTE) is a way to measure a worker’s involvement in a project. An FTE of 1.0 means that the person is equivalent to a full-time worker. Although the accepted HR  term for the “E” in FTE is “equivalent”, in colloquial usage or in project management terminology it is referred as full-time employee! FTE hours, can be used to measure whether an employee or resource is full-time, or how many students at an educational institution are full-time.

To better understand this:

• Start with 40 hours a week

Use 40 hours a week as your default for full-time employment when calculating FTE hours for a project. Some projects may measure full-time status differently, such as 35 or 37.5 hours a week instead of 40, so be sure to adjust according to your project’s requirements.

•   Figure out the number of hours in a pay period

Figure out the number of hours in a pay period by multiplying the length of the pay period by 40 hours a week. For example, if your pay period is 2 weeks, your total number of hours in a pay period would be 80.

• Divide hours worked by hours in a pay period

Divide the number of hours your employee worked in a pay period by the total number of hours in that pay period. The total equals your FTE hours. If an employee worked 40 hours out of 80 hours in a pay period, your total would be 0.5 FTE. It’s that simple!

Shyam Verma, PMP, ITIL

Program & portfolio Mgnt professional

LinkedIn:spverma. Twitter: Shammy11

Scope definition through User stories

User stories

The benefits of achieving a working software in less money, better risk mitigation mechanism (because you test early and test often) and dependence on process not individuals is one of the key reasons that XP has become one of the most preferred software development methodologies in recent years. Agile practitioners term User stories to be “Technique of expressing requirements as user stories to be an effective approach on all time constrained projects and are a great way to begin introducing a bit of agility to your projects & requirement management approach.”

If you happen to be one of those PMs who need to deliver your project in such fashion chances are you are most likely to use your scope statement e.g. project requirements in terms of user stories rather in standard functional requirement document. Hence it would be invaluable to know how you can employ user stories to define and plan project scope.

What are user stories?

A user story describes what functionality is required from the perspective of business users in simple or plain English running through different steps or stages to accomplish desired functionality. In simple terms, a user story provides the clear understanding of who wants the functionality, how it would work and why this functionality is required. In most cases user stories are written by customer or a customer representative working with a developer where developer may ask some questions to clarify the user actions but does not influence the idea creation process. User stories are used mostly in agile software development methodologies to provide the basis of features required in the software.

Development Process: While business user or customer narrates the scenario, developer makes notes on a 3×5 inch Card with functionality or requirement name, user action description, test condition, rough estimate and any other relevant point. For example, ” As a business user I want to be able to search for my customers by their first and last name,” or the “Application starts by bringing up the last document user was working with.”

The 3 basic tools used in the process are namely, Card as mentioned above, details around Conversation where details are noted as discussion with business user happens and thirdly Confirmation or Conditions that must be met for for the basis of user acceptance.

In case there is any ambiguity on the user story or it is deemed complex or too big the process of refinement is repeated until the story is concise and agreed by both user and developer. Please note the user story is not supposed to be definite business functionality and changes to the functionality are accepted at the time of development or even testing. From that perspective the process represents one of the key features of Agile development.

Advantages: User stories are a quick way of eliciting customer requirements without having to spend too much effort on formalized requirement documentation and bypassing overloaded administrative tasks for maintaining them. The purpose of user story is to respond promptly with less overhead in rapidly changing real-world requirements

Limitation: since the User stories are informal way to elicit requirement the test scenario for acceptance purposes should be in place without which the implementation of the requirement do not have customer acceptance.

Shyam Verma, PMP, ITIL

Program & portfolio Mgnt professional

LinkedIn:spverma. Twitter: Shammy1

There are three basic tools used in the process namely Card as mentioned above. Secondly details around Conversations where details are noted as discussion with business user happens and thirdly Confirmation or conditions that must be met for acceptance.