|Glossary Quick Links|
|Glossary Master Index|
|Discipline Quick Links|
|Disciplines Master Index|
The IT Project Framework (also known as the IT Project Management Framework) identifies, defines and describes the key activities that an IT Organization must perform, in each and every operating Environment, in order to successfully deliver a versioned Release of IT Solutions and Assets, such as Products, Software, Systems, and Applications to their intended Markets, Customers, Operating Environments and End Users.
Before getting into the Project Framework, itself, we first have to understand the definition of Project.
A Project, which is the enterprise noun that is critical to the IT Discipline called Project Management, is defined as:
Given this definition of "Project" as a basline, we can now define, both, a Business Project and an IT Project.
A Business Project is defined as being:
An Information Technology (IT) Project is defined as being:
In summary, an enterprise's Projects are typically broken down into two general categories, Business Projects, which represent Business-only or non-IT related Projects, and IT Projects, which represent any work being performed that involves any aspect of an IT Organization and any of its Products and/or Services.
As you read through this framework, you'll find some patterns that apply, both, to Business Projects as well as to IT Projects. Please keep in mind that, from this point forward, this framework is intended to specifically focus on IT Projects, only, unless otherwise specified.
Also, the IT Project Framework and the details, here in, are based on and align with the Systems Development Life Cycle (SDLC). This is intentional and has been done to show and maintain consistency and repeatability of learning constructs.
Many IT professionals view a Release as nothing more than a specific version of a specific Asset, such as a Product, Software, or System. However, a Release also represents everything it took to get to that versioned Asset or its state, meaning it is the sum of all its activities. These activities are the very same activities as those of the System Development Life Cycle (SDLC). Because a Release is the sum of all of its SDLC activities and represents the successful completion of one full iteration through the SDLC, a Release is also accepted throughout the IT industry as being an "IT Project."
Given that a Release is the equivalent of an IT Project, it goes without saying that a successful IT Project Manager "always" ensures that his or her Project Plan, revolves around, covers and accounts for all SDLC specific activities. Doing so ensures the highest level of delivery quality, while focusing on the most critical delivery Tasks or Activities. It also goes without saying that the success of a Release (and therefore also of an IT Project) is highly dependent on your SDLC being fully defined, as repeatable and as complete as possible. This is because if your SDLC is broken you ability to deliver such a Release or IT Project becomes a more difficult task.
With respect to versioning, Releases are always associated with an Asset, Service or a Capability and represent a versioning of such Assets, Services or Capabilities. The versioning acts as an identifier and often represents a loose measure of maturity and quality. Therefore, for example, "Product X -> Release 2.0" is almost always assumed to have more Capabilities and Features, as well as higher quality, than "Product X -> Release 1.0" did. Also, we would be able see clear differences between the two, making it easier to measure the two against each other.
If your enterprise does not use Versioned Releases as a way of controlling units of delivery and bundles of repeatable work activities for its Products, Capabilities and Services, it may want to reconsider doing so. Simply look outside your enterprise at every major technology vendor in the world to see that they are, in fact, using Releases as a way of controlling the development and delivery of their Products and Services to markets and consumers. Start by looking at things like your mobile devices, your laptops, your video game systems, your video games, your televisions, your software and your audio systems. All of these items are "versioned" in some way, shape or form. The names between such vendors' released versions may, sadly, not be consistent (you can thank marketers for such inconsistencies), however, you will find that each Product is relased to the market in controlled and identifiable (i.e. named) Releases with controlled Features or Capabilities, where the first Release might have certain Features and performance characteristics, where the second Release will improve on the first Release, causing the first Release to eventually become outdated and obsolete. The same pattern occurs when the third Release is delivered to market, later making the second Release obsolete. (Note: The Foundation always highly recommends consistent naming and versioning conventions of and between Releases of Products, Services and any other general Solutions that an IT organization delivers to its End Users.)
In summary, the typical IT Project is equivalent to one single Release of a Product, System, Software, Service, Capability or any other general solution that is delivered by IT to its End User communities, whether they be paying Customers or not.
Given that an IT Project can be represented as a Release (i.e. a single iteration through the SDLC), it now becomes apparent that each phase of the SDLC becomes a timespan of grouped or like Activities or Tasks in the Project Plan. This means that the end of every SDLC phase represents a major IT Project "milestone." This pattern can be applied as a consistent and repeatable pattern to any IT Project that focuses on the delivery of an IT Solution (i.e. a Product, Service, System, Application, etc.) The following figure is a high level example of what an IT Project Plan starts to look like when SDLC phases are used as the framework for laying out SDLC-specific Activities or Tasks across an intended period of time (in this example, approximately four calendar quarters).
The above example shows us that, when we use SDLC phases as the foundation for laying out our IT Project Plans, we start to clearly group "like" Acitivities or Tasks. It also shows us that using the SDLC as a baseline for IT Project Plan layout is a natural way to align Project Plans with what actually happens in an IT Organization, in order to delivery Solutions. You can argue that you don't need a Performance Testing Phase or that Training and Education comes after Production deployment or even before User Acceptance Testing. However, the premise of using SDLC phases to layout major milestones does not change from IT Project to IT Project and, as you'll notice, doing so becomes a consistent mechanism for not only laying out a project but also for measuring performance of IT Projects by SDLC Phase.
An IT Program, quite simply, is an aggregated and structured set of planned Releases (i.e. IT Projects) for any relevant Solution, such as but not limted to a Product, a Service, or Software, that is intended to be delivered to End Users and/or their Markets, by an IT Organization.
The above figure shows how a single Product, named "XYZ," is broken down into a number of different Releases, inteded to be delivered over a period of a number of years.
Looking closely at the above example, we can now see that any phase in the SDLC acts as a basic Milestone unit in an IT Project Plan, and all combined phases of the entire SDLC (i.e. one full iteration through the SDLC) represents a full Release or a full IT Project, and the aggregate set of Releases mapped out over time represent an IT Program. This is a repeatable and critical pattern to understand, when when you or your enterprise is trying to establish IT Organizations, such as IT Delivery Organizations, IT Project Management Organizations and IT Program Management Organizations.
Given that an IT Project is equivalent to the Release of a Solutions, such as a Product or Service, it would be an easy assumption to make that an IT Project Manager and a Release Manager have the same roles and responsibilities. However, this is not the case. IT Project Managers help Release Managers with Activities such as:
Unlike the IT Project Manager, the IT Release Manager has more responsibilities than the IT Project Manager because he or she must not only be concerned with the identification and execution of Release work but he or she also has the responsibilites of defining and delivering the entire Release, including but not limited to the identification of what the Release will encapsulate or deliver (i.e. new Features/Capabilities, modifications to existing Features/Capabilities, and Bug Fixes or Break Fixes for existing broken Features/Capabilities). Also, unlike the IT Project Manager, the Release Manager holds accountability for the Release, itself, and is accountable to the Product or Service Owner that is accountable for all Releases for their Products or Services.
The above figure helps us understand how IT Project Plans and the IT Project Manager Role fit into the bigger picture, as is relevant to Releases and Solutions.
It's critical to understand and keep in mind that, in smaller enterprises, the Release Manager often plays the Role of, both, the Release Manager AND the IT Project Manager (and often even that of the Product or Service Owner/Manager). This is often because of reasons such as there being less money to hire a separate IT Project Manager and because, in smaller enterprises, there is often far less Project "overhead," such as but not limited to things like Project Governance Activities and the coordination of Resources that are spread out across many different Organizations. As enterprises grow and can afford more reasources, they typically will break out each Role into separate individuals, which ultimately brings up costs, slows down delivery and brings down efficiency. This is why larger enterprises cannot typically deliver as quickly, as efficiently or as affordably as smaller enterprises that are considered to be "leander."
Because the SDLC can be standardized and because it is very repeatable, experienced IT Organizations use Project Plans Templates as tools to help standardize IT Delivery.
The use of Project Plan Templates has many benefits, some of which are as follows:
A mature enterprise usually has between three (3) and ten (10) standard IT Project Plan Templates, for common IT Project Types, that are published to all Project Managers and Project Teams for reuse. Examples include:
In addition to templates for very common IT Project Types, A mature enterprise also has standard IT Project Plan Templates for more complex IT Projects, such as...
Templates usually originate in the trenches. Smart Project Managers who realize they're repeating the same work for every Project, start to create templates to facilitate their work on future Projects that have similary traits. As an enterprise evolves and, ultimatley, establishes Project Management Centers of Excellence, such as what Program Management Offices are intended to be, the templates become more formal, more centralized, more standardized, and more accessible, throughout the broader enterprise.
You can always identify a good Project Manager because he or she looks for or creates highly reusable Project Plan Templates. You can easily identify a great Project Manager because he or she already has an arsenal of very detailed Project Plan Templates and demands that the entire enterprise use them, too, as a means of establishing consistency, reducing costs, and reducint delivery times.
The following represents what the Foundation believes to be a minimum set of summaries and conclusions that an IT Professional should take away, after reading about the IT Project Framework...