By using this website, you agree to the use of cookies as described in our Privacy Policy.

Bickenhill Lane, Birmingham, B37 7ES, UK
Mon - Friday: 9.00 am to 6.00 pm UTC+1.
 
Our localtion
Birmingham, UK.
 
Call Us Now
+44 800 3892348

Blog

The program may encapsulate a „big“ project but not another program.

The program may encapsulate a „big“ project but not another program.
Ratings
(0)

This topic is surprisingly old considering the history behind and the enormous number of projectized applications worldwide. And yet it’s still on loop most-likely, I suppose, when comparisons and business decision are made about the scale and the overall importance of both professional disciplines.

Nevertheless, the purpose of large-scale projects and the enterprise programs is distinguishable.

But first things first. Do we remember what is the meaning of the verb „project“? Actually, this word is older than all of us. The word root „projectus“ origins from Latin and means to thrust any known undertaking forward to completion. The modern and more comprehensive interpretation sounds a bit complex, of course, by defining the project as any temporary endeavour with definitive start and end dates intended to accomplish its goals and objectives to the satisfaction of the stakeholders.

The project should be considered also as unique in a sense it brings product, service or a result that didn't exist before. And, yes respectively, the projects are not repetitive and ongoing endeavours as the business operations are.

On the other hand, the programs is relatively modern term and are intended to deliver a complete package of work. This complex effort encapsulates the paradigm of managing collectively projects in a coordinated fashion in order to capitalise particular business goals and enterprise benefits that wouldn’t be achievable if the projects were commenced separately.

Both projects and programs are preceded by an evaluation process that defines the business goals and the expected added value to the organisation. In many occasions, these feasibility studies are performed as dedicated projects. And this makes sense, because the results might bring value to several consequent endeavours.

Obviously the programs are large endeavours by nature, but cannot be referred or substituted by the definition for a kind of "big" project.

Here is Confusion #1 - we might have supporting projects independently before particular project initiation and/or as a favour to other projects within a program.

Let’s dive into Confusion #2 - could we have sub-projects within a large-scale project? The short answer is Yes, we could. In fact, an entire project phase could be elaborated as a sub-project. Furthermore, some of these sub-projects might not be scheduled until a future date. Perhaps sounds unacceptable, especially for those followers of the traditional waterfall project methodologies, but for the large-scale PM this is a valuable technique, known as roll-out or rolling wave planning.

Compared to the programs - the sub-projects within a large-scale project are considered as major deliverables to the overall project breakdown structure, and as a such they should not jeopardise the project close-out and ending date. The programs are governing their subsidiary projects on higher level by global management framework and team, generally using mission statement to the stakeholders, strategic milestones, realisation plan and other program-specific components.

The programs, however, are not intended to manage other programs as it is eligible for the projects to include sub-projects. This higher enterprise level of coordination is handled by the portfolio management.

My colleagues asked me often how to roll-out sub-projects without impacting the P&PM time commitment? Well, this is one of the challenges in the large-scale management, but to keep it simple - the large scope decomposition subdivides the major deliverables into smaller components and makes them more manageable. The sooner the sub-project scope is defined the better. In these situations other skills are more than welcome, such as predictive risk assessment, requirements traceability, configuration auditing, change management and more…

The usage of agile techniques in large-scale ERPs is another measurable topic but due to its size I have decided deliberately to excluded it from the scope of this article.