There are 3 basic functions an IT Organization delivers for their customers.
1. Implement new systems functionality
2. Fix problems with the current functionality
3. Operate the current functionality
A distinguishing factor for each of these is a unique trigger or an action that prompts the work to be started.

These process definitions can be used to help the IT groups manage their work.  Each of these processes spans the IT Organization.  Some groups in the organization will take more focus in one process versus another.  For example, the functional organization group called Computer Operations will primarily be driven by the Operations process.  However, when a problem occurs, Computer Operations could very well be the area that identifies the problem, initiates the resolution of the problem and could be a part in working the resolution.

The point here is to separate the functional areas in an IT Organization that are typically tagged with these same terms from the processes that run the organization.

Some of the IT Organizational Groups will participate more heavily in one process than the other processes.  Below is a basic model for the IT organization and some of the types of work and what process generally manages the work.

*Core Business Applications – in an organization that supports a hospital, these could be Clinical Applications, a manufacturing organization could be Manufacturing Applications.   The larger the organization, the more these groups will be split.

One of the issues that could arise in the work flow is the line between a project and support.  I’ll look at that in my next blog.

I’ve done a lot of work over the years to help IT Organizations work more effectively.  Through these projects I’ve evolved my thinking into a basic model for how all the work can be organized.  In this, as in everything, it gets more complicated with actual implementation.  But I hope this will give you a basic outline to fill in the details.

Process vs. a Project

First, let’s talk about what is a process.  Let’s start by distinguishing a process from a project.  A project is a unique piece of work that generates some type of outcome.  In an IT Organization, one of those projects could be the Implementation of an Accounting System.  The emphasis here is on unique.

A process on the other hand is a series of series of standard steps that get repeated over and over.  Each set of steps is executed for an instance of the particular piece of work.  For example, after the accounting system has been implemented, new users will be periodically added to the system.  There is a “New Accounting System User” process.  Steps in this process could be:

1. Fill out the request form
2. Send the request to a manager for approval
3. Send the new request to the Systems Security team
4. Set up the new user account in the system
5. Communicate the new user account information back to the user

Pretty simple example, but you can see the flow.  Every time a new user is required, the same process could be executed.

On the Accounting System Implementation, since it is a new accounting system, with different features, the detailed steps you go through are unique.  And therefore doesn’t lend itself to a standard piece of work.  A good practice for organizations will put together methodologies for similar projects.  These methodologies organize the work in similar work groups, for example Design, Development, Testing and Implementation.  And this could be applied to every system implementation project.  It could provide an overall structure.  But the details of each of those phases are different.  I could go on about the advantages of a standard methodology, but that’s for another blog.

In the next blog, I’ll talk about the main IT Processes.

When a project fails, why it was unsuccessful is often a mystery to those involved. A project plan was created at the beginning of the project. Management agreed on the objectives and approved the plan. A qualified team was assembled, and frequent meetings were held to discuss status and update the plan. Yet, the project failed to achieve its objectives, went way over budget, or was never even finished.

I’ve seen many projects like this, and a key reason for their failure is trying to do project management without administering the project. Following are a couple of examples of things that have challenged me in the past and put my projects at risk:

Issues management. The biggest challenge with issues management is staying on top of myriad activities required to resolve the issue. On one project I worked on, the client insisted that we use their issue-tracking template. This Excel spreadsheet let us log the issue, the owner and the required resolution date. Typical, right? Well, I used the tool and followed up with the owners to ensure that the issue resolution was on track. As we started getting close to the required resolution date, I kept finding that the owners would say that they couldn’t have it done on time since they had prerequisite activities to accomplish.

I was able to mitigate this over time by breaking down each issue into multiple issues with multiple owners so that the intermediate steps could be resolved within the required overall timeline. It sure would have been nice, though, if I had a tool that would allow me to define the intermediate tasks required to resolve the issue and to track them in conjunction with the underlying issue.

Meeting management/commitments. This area just drives me nuts. If you are facilitating a meeting, participants are always saying that they will get something done by a specific time. Then, they leave the meeting and promptly forget about it. That is SO frustrating. I’ve had many times where I didn’t even realize that commitments hadn’t been met until the purpose for making the commitment in the first place became an issue. It would have been nice if I had a tool that would have very easily let me track these commitments and follow up to ensure that they were completed.

You might not think about what you do as Project Administration, but whether you acknowledge it, it is a big part of a project manager’s duties. Having the tools necessary to accomplish these duties allows the project manager to focus on the exceptions requiring attention, as opposed to spending all of your time seeing if people have done what they were supposed to do.

As has been said, project management is more of an art than a science. If you administer a project fully, you would never get the project done. There is a fine line between the necessary level of granularity and being mired in irrelevant details. It’s all about recognizing where the risks are, focusing on those, and making sure you have the tools in place so that all your team spends their time where they need. Proper project administration tracks, monitors, and manages issues, commitments, meetings, and scope at the proper level to minimize risk.

Commitments tracking, ownership, and dates. Commitments made outside those on the project plan need to be documented, and you must follow up on them. It’s common during a project for people to say they will get something done. If you don’t document these commitments and track progress on them, you will often be surprised to find that they aren’t done when they were supposed to. These commitments are often made in project meetings or because of an identified issue.

Meeting planning documentation and follow-up. Planning, documenting, and following up after meetings are critical. I wish we could get a project done without having any meetings, but that’s just not going to happen. Having something to give you the tools to minimize the pain of all those meetings is helpful. Meetings are not only checkpoints for project progress, but are also frequently the source of commitments, decisions, and issues. So, it’s very important to document and follow up on the discussions that occur.

Issues management. During every project, unanticipated issues arise that affect the project’s success. Often, project managers have an issues log to track issues. But the problem is that an issues log simply holds a record of the issue and some future date for resolution. Usually, many intermediate steps are required to resolve an issue. If you don’t identify and track these intermediate steps, you risk being behind the eight ball because things that were supposed to be done weren’t. Project administration entails more granularity of the tasking and responsibilities around the intermediate steps required to resolve an issue. Project administration focuses on the management of issues, not just issues tracking.

Scope change. One main reason to update your project plan is a change in scope. A scope change often results in delivery date changes and/or the need for additional resources. A major scope change is like replanning your project. Changes in project scope should be fully documented, and the impact of the scope change needs to be communicated and approved.

Next time, I’ll provide some examples of unsuccessful projects and the ways in which applying the principles of project administration could have helped.

Project Administration. If your first thought is of a project plan, then you’re not alone. Most project managers I talk to equate project management with building and maintaining a project plan. But project planning and plan maintenance is only part of the project-management process necessary to deliver a successful project. Project administration is the other and arguably more important process.

While project planning focuses on building an initial plan, project administration ensures that the things that need to get done during a project get done. These things might or might not be defined tasks on the project plan. For example, during a project, issues come up that affect the completion of a task. Identifying, documenting, assigning and tracking these issues to resolution is critical to any project’s success, but you probably wouldn’t update your project plan to incorporate any issues as they arise.

I guess if you, as a project manager, are 100% confident that the people assigned to tasks, issues, action items, and so on will do them the way they should and complete them when they should be done, then put the plan together, sit back, and let people execute it. But in the real world, I will make sure people get things done when they should be done, including many things not on the project plan and never anticipated when the project plan was built. These things make or break a project, and the project manager should focus most of his or her time on them.

Project administration handles things such as these that come up daily. If it is a very short, one- to two- month project, then it’s probably not an issue. But if you have a project that will take more than a year, it can get very challenging to stay on top of all that goes on. You obviously will not replan your project for everything that comes up, but these things still need to be managed.

Generally, project administration includes the following:

• Issues management
• Commitments tracking (including ownership and due dates)
• Meeting planning, documentation, and follow-up
• Scope management/change

Next time, I’ll discuss in more detail the components of project administration and include some recommendations for successfully managing each of them.