To start things off, when I say Schedule, I also refer to Programme, Plans, or a Bar Chart. In my opinion, these are all works of art that must always take into account the unique circumstances brought about by a new 'project', the organisation implementing it, and the end user.
But, in order to improve organisational learning and the way planning is applied to programme execution, the process of creating a plan must be as scientific as possible to avoid adding so many variables that it will never be beneficial.
I am constantly learning from both my own and other people's life experiences, and mine may be incomplete. I have worked in the Project & Construction management arena for over 30 years. A Civil Engineer by qualification, I have always had an enquiring mind and enjoyed the building process.... commencing as a 5 year old with Lego.
By the way, using the right tools doesn't guarantee that you'll make excellent plans; they are merely meant to help gather and present ideas. Utilising analytical methods like earned value or risk modelling does not imply that you are proficient in scheduling or, more crucially, planning.
Planning software is relatively easy to quickly learn the basics. A well known Windows platform is way too easy to get up and running. I was able to instruct my 10 year old son the 'art' of drawing 'pretty boxes' that looked like a Gannt chart. Start & finish dates were spot on..... shame about the logic. Step forward 15 years in time & I still see similar quality 'artwork'.
Based on my observations, over my career, the actual difference is in the way the strategy is developed. The creative strategy establishes the life profile of the product (or project), indicating whether it is a strategic tool to support programme execution or only a visual assistance to provide the appearance of a plan.
"Using a tried-and-true" framework, plans are developed to offer a simulation capability where circumstances can be assessed and scoped in an auditable setting. This essentially means that all planning activities may be verified against auditable data that belongs to personnel in the organisation who must keep this data up to date for business operations rather than programme goals.
This offers the structure for organising activities for a particular programme while taking the organisation's larger business goals into account.
What is crucial to the organisation's long-term business survival is the first choice it must make.
What is the primary cause of an organisation's growth and success? Based on the experiences of companies that reply with the cliché of "Make a Profit," this is a goal shift that overlooks the fact that they should focus on fulfilling the promises they make to clients.
In order to get the contract, these deliveries must be well-sized, and the program's operational area must contain a wealth of evidence supporting the expectations of the parties involved.
I've observed a lot of instances of businesses and programme management strategies that prioritise profits over all other considerations, with the goal of ensuring that the Estimate at Completion generates the anticipated profit margin. This strategy appears to be effective for a while, particularly when internal leadership is focused on Profit.
It is interesting to be involved in the entire project process – Feasibility > Documentation > Tender > Negotiate > Contract Award > Mobilisation > Delivery Manufacture/Install/Construction > Testing & Commissioning. It doesn’t take long (Post Award) that ‘making profit’ tends to become the priority driving major decisions.
However, in the long run, these organisations truly start to slowly deteriorate as consumer dissatisfaction grows and they have fewer opportunities to turn a profit.
"The most crucial aspect to baseline in a plan is the external deliverables defined by the contract, which means the customer/owner, followed by the internal deliverables identified by the organisation's programme management strategy, and last but not least, that which the programme manager defines as being additional to facilitate success."
Plans should be focused on achieving deliverables and displaying all the enabling activities that facilitate the successful delivery. This is the second set of restrictions that must be followed when creating the plan.
The organisation's reasoning for feeling that planning is required in the first instance should be ascertained next. Having worked for numerous organisations and in a wide range of areas, I have discovered that the biggest obstacles to the original purpose of planning arise from organisations that structure their operations around a number of projects and use inexperienced project teams.
Onboarding the right experienced people at the right time is essential to a successful project outcome.
In the initial instance, at least, the distribution of resources is fairly broad-brush. Here, the team is formed with loose logic techniques summary-style activities that are frequently observed, and resource allocation between particular top-level milestones as opposed to work-based activities.
This is effective as long as the resource estimate is based more on time than on product activity.
The resources will be managed based on a rolling basis against derived Level 4 and 5 tasks, rather than according to a cost profile for that particular resource type. Based on my experience, level 4 and 5 plans are where team leaders use products like Microsoft Project, and the like to help them.
The plans they use can also be linked into larger, more complex programmes like Primavera P6. This is something I support because MS Project estimates resources based on job lengths. The jobs' time and overall effort are specified and scheduled. Hours are computed for each resource when they are assigned to a task.
This is highly effective for short-term activities where deliveries serve as set, firm end points and task durations are defined or determined by interdependence between tasks.
When using the Work Package technique, the Manager of the Resource Family allots resources in response to requests that specify the hard or soft products that meet the requirements of the work package.
Any intermediate processes that will be utilised to evaluate progress and completion, such as design reviews, demonstrations, and acceptance criteria, must also be specified in the work package. The resource profile, total budget, and, when necessary, the identification of any named resources—people, equipment, or facilities—that are necessary to achieve success are then negotiated by the programme manager and resource manager.
Another strategy is to profile the work and utilise the step structure in the tool by using the timesheet and resource planning features of programmes like Primavera. The drawback is that specialised planners and schedulers are needed to use this tool and its high level of sophistication; in my experience, this does not make the updating processes more efficient because the owners of the updates do not have hands-on control and must develop trust with the site delivery team.
In the past ten years, I have worked with businesses that manage resources through work packages and are resource-constrained rather than time-constrained.
Allocation of Resources on a Plan must always take into account the availability of the resource and the other tasks already assigned, or potentially assigned, to them.
This strategy is made easier by tools like Primavera P6, which enables businesses to prioritise certain initiatives so that they are given top priority when resources become available.
So let's start with a common scenario that we encounter. We receive the order or contract for Project ‘Alpha’ and now that we have it, we just need to produce the results as agreed upon and within the specified contract requirements. In addition, we have obligations to the company that provides our renumeration.
There are a lot of competing demands and emotions that need to be controlled in order to prevent them from overwhelming us before we even begin. The best approach to start is to focus on the planning process.
The most crucial elements to comprehend before we start preparing, in my opinion, are what needs to be provided and by when. That's all there is to it. While we need to focus on developing a strategy, the programme manager must consider the wider picture of achieving the expectations of all the multiple stakeholders.
Finding the contractual deliverables, internal deliverables, interfaces, and unique needs of the programme manager—who is in charge of outlining the program's operational procedures—is the first step towards being able to accomplish that.
How well, therefore, did we do during the contract-winning process? Did we create a plan that fully utilises activity-based costing techniques and captures all of our knowledge? I really hope that we didn't as if we had, we would have wasted a large sum of money from our employers with little to show for it.
Due to the competitive market, the company field I work in now submits bids for a sizable number of programmes that it does not win. For the purposes of this example, I will assume that we have a relevant Level 2 Plan that covers the key external delivery Milestones and enough activities to demonstrate our approach to the customer. Planning to a Level 3 complexity during the bid stage would therefore be extremely wasteful.
Therefore, in order to construct a plan appropriate for baselining as the Programme Master Schedule, our first step is to take this Level 2 framework and grow it to Level 3.
Applying Burton's First Law of Planning is now necessary. "Using a tried-and-true framework, plans are developed to offer a simulation capability where found circumstances can be assessed and scoped in an auditable setting."
Throughout my career, I have employed a variety of planning techniques, and I have to say that no one approach has worked for me. I must admit that this isn't because of any shortcomings in any of them; rather, it's because of the atmosphere in which they are utilised.
In the Resources industry, for example, I discovered that the most efficient approach was to use pre-made templates that already had a logic captured and could be resourced profiled on a sliding scale based on the final activity durations chosen. Since these might be reused, it made sense to save them and utilise them again, since this would help with organisational learning and lower costs and planning variability.
But in the construction industry, the Template Library would have been so big that nobody would have chosen a standard framework or kept it up to date.
I'll be using a process methodology known as "structuralised planning" to assist this topic. Essentially, this follows a set of procedures to build, record, and then baseline the plan in order to include all pertinent structures required to uphold Burton's First Law.
There are five steps in the process, each of which must be completed before going on to the next because they are interdependent. Some may need you to go back and alter the output of earlier phases in order to complete certain reconciliation duties. The largest advantage, though, is that only auditable data is used at every stage, making it simple to determine what external actions your decisions result in.
Above all, the Programme Manager maintains complete control over every stage. However, the Programme Controller, who is in charge of construction, has a defined process in place to guarantee that all choices are made objectively and without regard to feelings or irrational expectations.
A very basic explanation of the five processes and the macro procedure used to specify which data is used is given in the diagram below. The creation of all programme structures, including job Breakdown Structures (WBS), Organisational Breakdown Structures (OBS), Product Breakdown Structures (PBS), and Cost Breakdown Structures (CBS), is predicated on the organisation executing the job employing the recognised technique.
has been determined to sufficiently encapsulate the objectives of the programme.
In order to fully capture the scope of expectations from all external and internal stakeholders, the milestone plan will cover all deliverables expected from the programme, both internal and external. At this point in the process, we can also specify the benchmarks and precise standards that will be applied to evaluate our development and document our accomplishments.
Plans must, however, be centred on attaining deliverables and all the supporting documents that enable the successful delivery. It is important to acknowledge that, at this point in the development process, the delivery dates are essentially aspirational.
Step 2: Activity Planning: This involves developing activity models that are sufficiently comprehensive to fulfil the specified scope of work. In other words, the activities will be collectors of activities that summarise the work execution details provided at Level 4, Work Package details, and Level 5 Resource Work Schedules.
This will result in an Integrated Master Schedule, or IMS, that we are seeking to develop, tailored to a Level 3. On the other hand, the Level 3 will be utilised to generate the Level 0, Level 1, Business Portfolio Summary, BPS, and Level 2, Programme Management Schedule, PMS.
I use what are known as "fragments of networks," or "Fragnets." which anyone who is old enough to recall Primavera P3 will be able to identify. In my opinion, these are not Templates; instead, they are not fully realised logical representations or dimensioned in any way. What I do is gather un-resourced plan fragments—basically just a series of logically connected activities without any external predecessors or successors—and store them in the database of the planning tool I'm currently using—It's usually Primavera P6.
Then, as I'm creating the plan, I use the fragments to create logic between the milestones. I will add more activities to these fragments, connect them correctly, scope the timeframes required to fulfil the Objective dates, and discuss the outcome with the Programme Manager.
At this point, it seemed inevitably hopeless, and if we followed this plan, we would almost certainly fail. What it does do is highlight possible bottlenecks and areas of failure, which we will need to address if we are to succeed after reviewing the logic with the work package managers and the programme team.
Now that we have a feasible implementation plan, it is time to tackle Step 3's most challenging step: resource planning.
"The allocation of Resources on a Plan must always take into account the availability of the resource and the other tasks already assigned, or potentially assigned, to them.
Therefore, in order to determine the type of work that must be done in order to achieve our goals, we have conversations with the performing resources. We validate or invalidate the hypotheses put out in the bid and Milestone setting. We determine which critical resources—people and material—are available, and after much wrangling, we reach a solution that everyone can live with.
This can entail asking Executive Management for permission to ring fence some important resources for the Programme Manager. It might even entail getting ready for talks with the client about changing the dates in the contract; these wouldn't happen until the following step is finished.
In order to reduce the likelihood of negative cash flow for the programme, the following phase, phase 4 - Budget Planning, involves modelling the cash flow profile of the developing plan and reconciling it against the contractual flow. When this is completed, the programme manager's job is to optimise the effects and try to limit the damage by renegotiating with the client.
After completing all of this, the company can now prepare appropriately to handle the effects since it is aware of the risk exposure it has in its cash flow.
Now that the program's ideal environment has been established, Step 5—Risk Planning—can be started to create reasonable expectations for the difficulties the programme might encounter. Setting programme baselines for schedule, costs, and resource profile performance comes next, once as many of the variables as feasible, have been reconciled.
After this is accomplished, we will have an Integrated Master Schedule, or IMS, that we can utilise for both the official programme launch and as a benchmark for success.
The core team continues working on advanced procurement, bid data evaluations, team skill analyses, and other tasks while all of this is going on.
The programme manager is completing the PMP, or programme master plan, debriefing the bid team, and setting up other components including opportunity and risk registers and metrics definitions.
In order to make such tasks possible within this time, it will be important to provide certain pre-planned work packages with a precise scope, a stated limit of liability, and other necessary details.
After the programme has been designed and sized, we must now move on to the most difficult task: executing it to the satisfaction of all stakeholders.
That is a whole different story.
How successfully have I now argued for my views that designing plans is an art and that they should always take into account the unique conditions brought about by a new programme, the organisation implementing it, and the end user?
Furthermore, the process of developing a plan must be as scientific as feasible to avoid adding so many variables that it will never improve organisational learning or the way planning is applied to programme execution.
The artistic aspect is always more challenging to describe, but I think I've managed to demonstrate that you can't design a plan in a vacuum; rather, you must make decisions about what details to include and how to proportion it. For me, a masterful work of art is when a logically connected schedule completely resolves and produces the desired results.
Comments