IT Project Management – Setting Up and Delivering IT Projects

Once upon a time, 30 years ago, I accidentally got involved with IT Project Management. I didn’t know it at the time, I was just in a place, at a time, and my work became a project. I didn’t even realize it was IT Project Management that I was doing then, I just had a job to do and did it.

Over many years and many continents my work has become much more formalized as a project mgr. Not that many years ago, I decided to get some proper training and took a Prince 2 course, and certified. Of course, I thought I knew it all. I knew enough to be dangerous and a little more to stay on top of things and no more than that. Taking a Prince 2 course 25 years after I started working was an eye opener. I recommend it to everyone!

Don’t under estimate the value of good training in IT project management, but just as importantly, don’t over estimate its value either. Too many people that pass through project training are never guided into the real-life application of their new found knowledge. Certification is not proof of a capable IT Project Manager.

Just Good Common Sense?

I always thought basic IT project management skills were little more than good common sense. I still believe that. Over the years I’ve become a little jaded and have come to realise that one of the rarest things in this world is good old common sense, especially in the world of IT Prj. mgt.

IT Project Management is NOT a black art, contrary to public opinion. It’s a simple process of gathering requirements, developing a solution or road map to deliver that solution and then delivering it.

Obviously there’s a bit more to it than that. The devil is in the detail as they say, but in principal that’s it. Imagine being asked to go out and buy some milk because you’ve just used the last of it at home. The requirement is easy to understand – a new bottle of milk should end up in the fridge.

But you have to know where you’re going to get it, how much it will cost and roughly how long it will take you to get it. IT project management, indeed any form of project work is just an elaboration on this process. This elaboration is a necessity when it comes to complex projects and projects where significant amounts of money are to be invested.

So what’s in the road map? The basic road map looks something very similar to this;

  1. Scope – get the requirements and agree them with the customer
  2. Plan – Sequence of tasks, timing, resources needed and costs – get these agreed by customer too.
  3. Control – manage the delivery according to the plan, within the schedule and budget.
  4. End – make sure your customer agrees what you have delivered is what was asked for.

Methodologies

Years ago I worked for a consulting practice and they had their own methodology for IT project management. They called it PACE – Plan, Activate, Control, End. They later updated it and called it EPACE – Engage, Plan, Activate, Control, End. In essence this and all the variations of IT project management methodologies – PMI, Prince etc., all cover the same ground. IT Project management is a well defined set of processes combined with common sense and experience. Applying these processes in IT Project Management is what most Project Managers fail to do well.

What was interesting then, was that the this IT Project Management methodology singled out the “Activate” stage as a special attention task. Having done the Prince 2 course and having written several professional development courses for PMI in the past, the “Activate” stage is one of those steps that often get insufficient attention, if any, in the real world. More on this in another article.

Each of the 4 main areas is a skill to manage in its own right.

  1. Understanding exactly what the customer wants. Developing a clear and concise scope of work, and getting it agreed can take a lot of effort and time. Sometimes it’s very quick and relatively easy, for example, a number if investment banks I’ve worked for have templates for new offices, data centres, trading floors etc., so when it came to developing a scope and associated costs and schedule it was quick, accurate and easy – “just tell me how many people as our spreadsheet tool will do the rest..”. On other projects – getting any form of agreement on the customer’s scope has been almost impossible – all the way to the end of the project. Life is never simple, projects are about people. Period.
  2. Producing a schedule, budget, risk assessment, communications plan, quality plan, reporting templates, and engaging the right resources – internal and external staff, is time consuming but vital if the project is to run smoothly.
  3. Managing the delivery or controlling the project delivery is where 75% of the IT Project Management time is spent. This phase also includes having a process and procedures for incident management, change management, inventory or configuration management and resource management. If you don’t do any one of these you’ll be in deep trouble.
  4. Closing out the project – making sure you get agreement on the quality of deliverables – i.e. they meet the customers expectations. Reporting final spend, carrying out a handover to operations and closing down the project  – invoice payments (or accruals), contracts for external resources, configuration management (inventory and documentation) all passed to the customer.

Can you start to see that within each of these phases there is a world of potential for confusion, disagreement, problems and sleepless nights of stress and worry? When you’re managing millions of dollars of a customer’s investment in a project – you better believe it.

Some projects can take several years to complete and managing the challenges of basic IT Project Management responsibilities becomes something you “live”. It’s not always fun, enjoyable, or pleasant. But there is a great deal of satisfaction to be had if the job is done well and the customer gets what he asked for at the end.

IT Project Management is a real life challenge. Projects are about implement change and managing people to make that change happen. Never under estimate the true value of a good project manager. They never earn their real value compared to the effort, experience and skill they bring to a job. Few people outside the IT Project management industry understand what they do.

IT Project management is “the application of common sense and pragmatism to facilitate people to make defined change”.

Small Business Project Management: Six Pros and Cons

Growth hungry small businesses today in the UK and indeed throughout the world face the challenge of balancing two competing objectives. Firstly, businesses must maintain and standardise current business processes in order to give your business the chance to get really good at what it does through experience curve effects. Greater business efficiency normally translates into a better customer experience and higher profits. Secondly, businesses must transform business operations in order to survive and compete in the future. How well we are able to achieve the right balance for our business will ultimately determine if we survive and go on to thrive or go the way of so many small businesses into market irrelevancy and insolvency.

You may well be thinking right now what has this got to do with project management? To understand that we first need to understand the fundamental differences between projects and day to day business operations. Whilst many of the skills required to manage your “business as usual” activities are the same as those needed to manage projects, there are some crucial differences. Amongst the most significant differences are that project work tends to be at least cross functional and often cross organisational and every project will be unique in some way rather than following the predictable pattern of business as usual. These characteristics of projects introduce opportunities and risks over and above those encountered in business as usual. In short, projects are riskier than day to day business, and therefore need a different management approach.

Projects are the means by which we introduce change in organisations. All businesses that are making any attempt to adapt to face future challenges have projects. Common examples of projects in small businesses may include setting up a company website, establishing the office in a new location, or implementing a new product but it can be any temporary activity or set of activities that have a specific output associated with it. Businesses increase their productive capacity one project at a time. Indeed, for ambitious small companies looking to grow and expand, the need to initiate the right projects and achieve the desired results is even more vital l than it is for huge national and multi-national businesses

Despite the obvious need for a project management (PM) approach, most small businesses don’t bother. This constitutes a huge missed opportunity as effective project management impacts the bottom line. For example, research by the CBP shows that project management improvement initiatives improve project performance by up to 50% for the first project and can continue for each new project if the business offers ongoing project management tools and support. We could emphasise this point further by citing the Standish Group, who in their CHAOS Report conservatively estimates that 20% of money spent on projects is wasted because companies don’t have a consistent approach to project management.

Let’s take a look at six reasons I often hear from small business owners that choose not to bother with project management and then critically address the misconceptions behind these reasons.

1. Project management practices take more time

Having a process to follow may add time to the duration of an activity. Doing something properly will almost always take a little bit more time than adopting a slapdash approach. However, if you where building a house, would you rather have a quality end result that took a little longer, or would you prefer to have it done quickly but with lots of problems? Given that poorly executed projects can be completely de-rail a small business if they go badly, doing it well is essential, and PM processes help ensure things are done well.

2. Project management eats into the cash that I need to grow my business

A common misconception is that it is hugely expensive to implement PM process. The reality is that there are many free or low-cost sources of advice, techniques, tools, templates and project management services readily available and accessible through the Internet. If done correctly, any small business can implement PM processes, techniques and tools with very little cost. The likelihood is that small business owners are already using software and other tools that can be used for project management. For example, certain email software, spreadsheets, and other common software applications offer good templates for project management, especially if used in collaboration with some of the low cost project management services available for small businesses

3. Project management requires skills that I don’t have and cannot afford to hire

Although it does require specialised skills and experience to be an accomplished project manager, these are skills that can be learned over time. To move further up the learning curve faster, it is possible to take a PM course in as little as four or five days. Most small business owners tend to possess the knowledge needed for project management, and courses such as the Prince 2 Practitioner course would build on these skills while introducing the specific theories, tools, and processes essential for project management. Whilst business owners might not emerge from a course as a project expert, they would certainly learn valuable skills to apply to their small business.

4. I don’t need the hassle or paperwork of project management.

Every entrepreneur that starts their own business will, at some point, need to do a risk assessment, a marketing campaign or apply for finance. Being knowledgeable in project management and applying associated tools such as stakeholder analysis, communication planning and risk management will not only assist in many of these tasks, but will provide your small business with a competitive edge over competitors who do not approach.

5. Project management will slow me down and I need to stay agile.

Modern PM methodologies all acknowledge the importance of a tailored approach to project management. If your project requires speed, the right methodology can enable you to move quickly. Just as important, however, it will provide you with techniques to understand whether some proposed projects are worth pursuing at all. Rushing into situations without thoroughly understanding your environment is hazardous to the health of any project and potentially to the health of the business as a whole

6. I am an expert in my industry, I don’t need project management.

Most small businesses are started by a person who already has some expertise in their industry. This is unquestionably an advantage; however, project management should still be used to convert plans into reality. The main reasons for project failure tends to be poor planning, lack of capital, and lack of management. Project management, while not a cast-iron guarantee of success, will assist the small business in mitigating some of the common risks that so often cause project failure amongst small businesses.

Even a brief look at the reasons often posited by small business owners for failing to approach projects in a systematic and different way that recognises their inherent riskiness and addresses some of the more challenging aspects of project work shows them to be of dubious merit. Without question, the quality of project outputs would be greatly enhanced and the cost of and time taken in delivering project benefits using a project methodology appropriate to the scale of the project.

Transition to Critical Chain Multi-Project Management

Transition to Critical Chain Multi-Project Management for Long Duration Projects

What to Do Until Buffer Management Kicks In

Abstract

The transition from traditional project management to Critical Chain Project Management (CCPM) in a multi-project environment presents a formidable problem with projects of long duration. A simple method is presented for that transition and provides the metrics necessary to directly encourage and cement the behaviors needed for Critical Chain Multi-Project Management. This paper assumes the reader is familiar with CCPM.

The Multi-Project Implementation

This paper focuses on the period of time from planning the first Critical Chain (CC) project, the cut-over project, to completion of the last traditionally managed project. This can be a long period of time before the company has fully implemented Critical Chain Project Management. Theory of Constraints (TOC) practitioners involved in Critical Chain Mulit-Project Management (CCMPM), often find this transition to be the toughest part of an implementation.

The Implementation Conflict

In order to successfully implement Critical Chain Multi-Project Management, we must obtain support for it. Everyone expects that CCPM will be another flavor-of-the-month implementation that fades away if properly ignored. To obtain that support, we must start with one project to prove that CCPM works. And to be successful, we must change the whole project system to CCMPM. Because Critical Chain requires Buffer Management and traditional projects can’t use it, we must implement CC on all projects at the same time.

Implement One Critical Chain Project First

Even though we know it works, we must prove that it works “here!” A common solution is to use a pilot (trial) project as a way to demonstrate CCPM and get the bugs out of the existing system. One project at a time is much simpler to implement than many. The pilot project should not be thought of as a trial. It’s really the first Critical Chain (CC) project, the cut-over project. Every new project following it will also be a CC project.

Typically, for a transition, the cut-over project is planned while the work-in-process is ignored. But in a multi-project management environment, that means that some or many shared resources will be fought over by the CC and non-CC projects. The resources are usually expected to multitask and have several projects in work at one time. Multitasking is a huge factor in projects being slow. How can scarce resources be assigned where they are most needed, if the statuses of these projects are measured differently?

The common approach to adding a new project to the pipeline of projects is to commit to a date and put it in the system. With little understanding of the amount of work in the system and the system’s capacity, work is pushed in with the expectation that it will get done.

With a system full of work-in-process projects, it will take a long time to complete this first CC project. Continued multitasking between projects will assure it. The reality is that people are asked to not multitask on the CC project while they are multitasking on the others. The non-CC projects will delay the faster, CC project. It will be difficult to determine and measure the Critical Chain project’s success compared to the others. Some people will believe it gets special attention and will demand to share its resources.

The more difficult problem is the lack of Critical Chain buffer management. Lacking CC project buffers, traditional projects can’t use buffer management. Priorities among the projects may be determined by perceived urgency as expressed by the project managers. Implementing the first Critical Chain project has not always been easy.

Big Bang Approach

The whole project system can be changed in one massive replan of all projects. It may make a lot of sense since we know we won’t be done until all the projects are CC projects. All projects are measured the same way and they quickly get up to speed. Or do they? How does the whole system get changed? All of the projects must be re-planned and changed to CCPM by shortening the duration of many, many tasks of many projects.

In a small system, the big bang approach is a real option. In a large system, it is definitely much more challenging and probably not possible. To change all the projects to be Critical Chain projects requires re-planning while they are in progress. The same people that are working the projects are need to do the replan. It’s likely to be chaotic and it won’t happen overnight. Re-planning will delay the implementation, delay current projects and may jeopardize an initial (or any) success. Just the opposite of what was intended.

Delay Until the System is Ready

Do not insert the cut-over project until the resources can focus on it. Prioritize the projects. Since any prioritization is effective in increasing the speed of a system, use the commitment dates as priorities to help determine what to focus attention on. Propose a drum resource and plan the release of the cut-over project to be synchronized with this drum. That sets up the next issue. How do resources (and management) know what to work on next? We need buffer management. We still can’t have it.

Unfortunately, it is not possible to start with a clean slate, no projects. We must deal with the work as it is in the system. It looks like we have to wait to use buffer management until after all projects in the system are CC projects. We still have an implementation conflict.

A New Approach

Create a method of comparing a Critical Chain project’s status with a traditionally managed project’s status, while promoting better behaviors.

(1) Prioritizing the work allows us to recognize that some work may be low enough priority to be delayed or canceled. Use buffer management on the first CC project, and create a kind of virtual buffer for the other projects. Then use virtual buffer management on all of those projects without re-planning them.

(2) Collect status for all projects as “How long until you are done with your task?” If percent complete is provided, accept it and restate it back as, “Does that mean you have 5 days of work remaining and you expect to be finished by next Wednesday?” Also ask, “Is there anything else you are working on?” Be consistent and persistent in asking for work remaining. Don’t argue about it. Accept whatever they give you. Reality will show up eventually.

(3) For each main chain of tasks (the Critical Path) and each feeding chain, compare the planned (base) finish with the current expected finish. The status (days ahead or behind) relative to the plan indicates how it is doing. This same calculation is done for Critical Chain’s buffer management and is called buffer incursion (in days).

(4) This information is used to manage the existing projects with their current due dates, without adding buffers to them, to create an unbuffered management report. The process is to prepare the existing projects by inserting a milestone at the end of the project, and between each feeding chain and the critical path. The milestone, being the last task in the chain, indicates the planned finish of the chain. As status is added, the expected finish of the current task pushes all successors to the future or pulls them earlier. Do NOT recalculate the critical path unless it makes a significant difference to the flow.

(5) Compare the current expected finish date with the base milestone (planned) finish date. This becomes an unbuffered incursion and can be reported and/or plotted for each chain of the project. Unbuffered Management can be used for all the projects, including the Critical Chain project. This provides a way to compare the health of all of the projects and a gives a basis for assigning scarce resources. The Critical Chain project would also have a Critical Chain Fever Chart and Buffer Report.

Unbuffered Management

Create a chart with % Complete on the X-axis and Days Ahead/Behind on the vertical axis. The chart will have characteristics like a fever chart. Place a zero line horizontally (exactly on schedule), and plot days behind above and days ahead below the line. Like the fever chart, it is a visual indicator that the projects are gaining or losing ground. The chart indicates how each the project is doing and its likelihood of completing on time. It has a virtual buffer. The buffer is really not there, but its usefulness is.

Traditionally managed projects typically have significant safety in each task in a futile effort to get every task completed on time. Most project managers either believe they have little or no safety in their projects or they believe that their safety is a minimal requirement to maintaining their schedule. They have substantial experience to prove it. They know that time and Murphy are very fickle. By using unbuffered projects, they keep their original task estimates and project due date. By adjusting behaviors toward Critical Chain requirements, task safety is much less needed and will accumulate at the end of the project. All projects are likely to go faster than they were. Project Managers see real results on their existing projects and look like heroes.

Conclusion

Critical Chain Buffer Management provides focus for management attention to significantly improve project performance. Since it is extremely difficult to transition from a traditional project management system to CCMPM, a transition methodology providing tools similar to Critical Chain Buffer Management is a significant bridge for that gap. With prioritization and unbuffered management, attention is focused where needed. Then good behaviors and a Road Runner ethic are developed, with the focus on completing as soon as possible, rather than on meeting the due dates. All of the work takes advantage of unbuffered management and the whole system flows faster during the transition.

This methodology is only for the transition to Critical Chain Multi-Project Management. It is not to eliminate buffers. It puts all of the projects on a level playing field until the transition is complete.

What to do until Buffer Management kicks in? Be doing Unbuffered Management!

Copyright Skip Reedy, 2002, 2011

Reprint allowed with credit