Seema Sonkiya: Project Schedule Important Points

Based on PMI and Agile methodology

Here my emphasis is only to describe important points; those are not covered in PMBOK 4 in detail. This article can be considered as an interpretation of PMBOK 4 along with incorporation of agile methodology good practices.

A project is in existence to achieve one or more strategic business objectives.  A project is initiated due to either internal business needs or external influences. When project is initiated means we have already done high level analysis that project will be successful given all identified constraints of schedule, cost, budget, quality, human resources, risk and availability of suppliers if project demands.

Project is initiated and now we are in planning, first step is to identify project and product scope this includes characteristics of product, service or result and work that need to be performed to get those features and functions.

Project and product scope can be managed with increments, and it may be defined progressively for each increments. When scope is defined and approved next step is to plan project schedule and establishment of schedule baseline either for whole project or for current increments, schedule for other releases may be still in high level and it can be defined in greater detail in next iteration of planning.

Schedule development is iterative process even for same release. Iterative development is essential for achievable and realistic schedule so that we can execute this to satisfy project requirements as per defined plan, which also includes approved project schedule and serve as a realistic basis for monitoring and controlling of project schedule.

Why schedule development is iterative process even when we are doing greater level of planning only for current release will be explained at the end of this article.

Steps to develop a realistic and achievable schedule, Here steps are specified for planning processes not for initiation process where high level schedule is developed:

1.       We need schedule methodology to develop project schedule. It is provided by organization process assets in mature project organizations and tailored to specific needs of project. If it is not present then it should be developed because we need to understand how to plan before actually doing it and in addition common understanding of planning approach should be developed and discussed with project team members and other relevant key stakeholders like customer who are involved in planning.

2.       We have schedule methodology and to plan project schedule we also need complete and clear project and product scope that is scope baseline developed either for complete project or for current release whatever is applicable.

3.       Scope baseline comprise of approved project scope statement, WBS and WBS dictionary.

4.       Scope statement is needed to review deliverables. Lowest level of WBS defines work packages that are basis of scheduling, costing, quality planning and controlling. WBS dictionary further explain work package. We define in schedule methodology that whether schedule will be developed at activity level or work package level. PMI says that schedule is developed at activity level. In case project is very large then there may be thousands of activities and in that case project managers find difficulty to draw network diagram and they prefer network diagram at work package level. Here I will follow PMI guideline.

5.       Define Activities: According to PMI work package decomposition result in activities. In agile functional requirements are converted in user stories. These are set of scenarios or transactions tied together with a common user goal.  So as per PMI we call result of work package decomposition as activities and in agile these are scenario of a use case (in case of functional requirements). Use cases are developed only for functional requirements.

a.      We need to identify activities using decomposition of work packages. Work packages are deliverables and activities are actions to complete those deliverables.   

b.      Activity attributes are identified needed for schedule development.

c.      During activity identification, Level of effort, Discrete effort and apportioned should be carefully identified.

d.      I have found very excellent definition during my research:

                                                               i.      Discrete Effort (DE )is measured based on defined tasks or activities identified as work and planning packages resulting in a particular product or service.[

                                                             ii.      Apportioned Effort (AE)is a task interdependent to an appropriate DE work or a planned package, such as a review or an inspection, and is measured as part of that task that supports the results in a product or service

                                                            iii.      LOE is “effort *work+ of a general or supportive nature which does not produce definite end products and cannot be practically measured by discrete earned value techniques.

e.      If we would like to differentiate which project management activity is LOE and which one is Apportioned we can use following logic:

                                                               i.      LOE is supportive project management activity and effort of this activity is dependent upon corresponding discrete effort activity. For example inspection of discrete effort.

                                                             ii.      Apportioned is independent from discrete effort, for example daily standup meeting in scrum project management methodology.

f.        Activities should have unique names. For example – ‘Displaying the details’ it’s not recommended instead it should be written like as ‘Displaying the details on order page’. If names are unique, we would be easily able to find mistakes and we can understand them outside the WBS also.

g.      Activity names generally use a verb or something equivalent as these are specific action to complete work package and work package define a deliverable both project and product deliverables.

6.       Define relationships: We have defined activities and it’s time to define dependency between activities. Dependency determination affects the pattern and usage of resources. Agile methodology says that during sprint planning meeting, we give emphasis on common understanding of work (in PMI activities) and team members are encouraged to select work as per their interest and skills to promote team building. This is an example of self organization in agile. Here I would like to add that during resource allocation in sprint planning we need to also consider dependencies of activities and resource availability as per need of schedule of that activity. Co-location in WAR room is perfect place to discuss these items and WBS may be pasted on WAR room walls.

a.      So we are in process to identify dependency of activities to define network diagram, and first step is to identify dependency or logical relationship between activities. There can be four types of relationships: FS, SS,FF and SF. SF is not used because it forces successor of an activity to put before predecessor.

b.      Important note is here to note when are in process to scheduling of activities, we also do that for scheduling of milestones.

c.      Each activity or milestone except first and last has at least one successor and one predecessor. If it not true then it’s very difficult to identify any influence of that activity to others or from others.  In this case some of the activities may be out of network this works against the reality of the project work and in result schedule will not be realistic and performance information and delay analysis will not be realistic.

d.      If an activity does not have any predecessor or successor then it should be connected to either start or finish milestone. If an activity does not have predecessor then it can start on first day of the execution, if it’s not true then we have not identified some relationships.

e.      Each Activity should have at least one FS or SS predecessor and at least one FS or FF successor. Because start of an activity is influenced by its predecessor due to FS or SS relationship and finish of an activity influence its successor due to FS and FF relationship.

f.        Most of the relationships are modeled with FS relationships; the fact is that most realities are best modeled with FS.

g.      The most common use of SS is when we hear this: … and activity B starts at the same time as activity A… and we make an SS relationship for B. usually means that B has the same predecessors as A.  We will need to enter more relationships in this case. For example, if we have 16 predecessors for A, we will have to enter all of them for B. We can also use a milestone instead. Give all the predecessors to the milestone and make A and B the successors of that milestone.

h.      When we have lots of successors based on lots of predecessors, we actually have an important event and we’d better design a milestone for that. This kind of milestone is sometimes called a toll-gate milestone.

i.         Another example: activity A and activity B have 10 days duration, and activity B has a 50% overlap with A. We might use SS+5days for B; but FS-5days is a better one.  Refer point f.

j.         Always count the number of activities with FS relationships; if they are less than 90% of all activities our network logic is not good enough.

7.     Applying leads and lags:

a.      We should not use large lags; there is always an alternative to avoid large lags. It is recommended that lag length should not more than 5 days.

b.      We need to use lags as little as possible. Lags are not strong scheduling elements. It is not enough to limit the length of lags if we are using them in most activities. It’s not natural to use them a lot; lags should not used in more than 5% of activities. If it is hard to implement then we need to think about finding more relationships adding the necessary constraints (if any) and finally breaking down our activities to have more flexibility on relationships.

c.      We should be careful not to use large leads, because leads are usually misused and hard to manage. For example we are using FS relationship, later on we get behind schedule and we have to compress the schedule and relationship become FS-5 days. The same things happen and FS-5days become FS-10days, FS-15days and ….. This is misuse of leads as it can introduce risk because successor activity may need accurate information from predecessor to start.

8.       Determine resource requirement: Network diagram is completed and now it’s time to identify resource for each activity. We need to consider resource availability, their skills and competencies. Activity duration is determined after resource determination because resource availability, skill, competency considerably affect activity duration.

9.       Determine activity duration: Now it’s time to identify duration for each activity, duration estimate depend upon availability and quality of information. Duration estimates preferably estimated in range. In agile it is estimated in ideal days. I recommend whether we estimate in ideal or in man days, it should be in range especially for discrete efforts. Length of range indicates level of risk involved in activity. Activities should not have large durations, it’s also supported by agile. PMI says that we should not have durations longer than two control periods in any normal activity. If it is not possible then we need further decomposition.

10.   Now it’s time to finalize schedule, it involves:

a.      Schedule network analysis is performed; often it need review of resource and duration estimates.

b.      Critical path is generated. It is recommended not to have large floats. We do not have any direct control on floats. Large floats are just a symptom of weak relationships.

c.      Check activity floats; if they are larger than expected, we may realize that we’ve missed something. Perhaps some relationships are not implemented; maybe some of them are wrong, etc.

d.      Always try to make milestones for date constraints. Date constraints are special; they are reflecting an important event in our plans. We are used to seeing events as milestones, so why don’t we limit date constraints for milestones?

e.      Now, to finalize schedule we need to:

                                                               i.      Perform What if scenario to determine schedule feasibility under adverse conditions.

                                                             ii.      Resource leveling to optimize resource allocation

                                                            iii.      Schedule compression by crashing, fast tracking or re estimating.

f.        Schedule is finalized using schedule development processes, but complete finalization needs some more efforts like:

                                                               i.      We need to meet resource manager to confirm resource availability; schedule is preliminary until resource confirmation. Any change in this confirmation may need schedule change; it can be done without change request as schedule is not present as a baseline.

                                                             ii.      Adjust component of schedule as result of risk response planning, because some of the WBS components need to be change as a result of risk response planning. Again change request is not generated.

                                                            iii.      Give the team a chance to approve the final schedule; they might have estimated an activity, but they should look at the calendar allocations of their estimates to see if they are still feasible.

                                                           iv.      Conduct meetings and conversations to gain stakeholders buy-in and formal management approval, this time change request may be generated to change project charter preferably to update schedule milestones. This is the responsibility of project sponsor. Any change in project charter is the responsibility of project sponsor. Other change many be initiated like scope change in response to balancing the constraints.

11.  Schedule iteration, some examples but not limited to:

                                                               i.      During cost estimation after schedule development, it may be needed to alter project schedule in response to time sensitive information that effect project cost. Change request is generated as it is change in baseline.

                                                             ii.      Quality planning need schedule baseline as input, planning may identify quality activities, which can change components of WBS to manage schedule performance.

                                                            iii.      When resources are acquired, it may trigger change.

                                                           iv.      Steps third and fourth are repeated of previous point in case of iteration.

Realistic schedule development is very important for the basis of monitoring and controlling.

Seema Sonkiya