1.1 Understand the general characteristics of projects
1: Why Projects?
1.1 Understand the general characteristics of projects - Video Tutorials & Practice Problems
Video duration:
15m
Play a video:
<v ->Projects are all around us.</v> Examples of projects exist in every setting in every work setting, but also in every public setting as well. Let's just take some examples, and this is a very diverse set of examples from a very broad base. But to give us a flavor for what we're talking about when we think of the word projects and what those can actually encapsulate. We have examples of projects, everything from pharmaceutical testing and development to construction projects, some massive projects such as the channel tunnel that was dug between England and France some years ago. We have examples of new products, the flashy or the fast or the smaller, these kinds of products that people need. The latest being the Apple Watch. We have examples of information technology system development projects that occur all the time where we're developing new software products or we're implementing IT systems into an organizational setting. So just to give an idea of some of these different examples we start seeing a interesting phenomenon, and that is projects perhaps in the the older days when maybe some of us thought of projects was a much more specific, precise sort of category. We thought of projects as being in the construction arena or perhaps aerospace and automotive but we really didn't consider the full breadth of organizations that are running projects and the manner in which they do the projects and indeed the projects themselves and how diverse they are even within the same organization. So much hinges on successful completion of these projects that a famous business consultant named Tom Peters, you can see from the screen here, has talked about this some years ago where he said it's not the repetitive tasks anymore. It's not the necessarily the operations of an organization, it's the projects themselves. Those things that we create that are the basis for the value-added that's going on in business these days. So let's ask the obvious question and hopefully we can answer it. What do I mean by a project? We've all heard the term. In fact, most of us have been assigned to projects in our organization. We maybe we use the terminology rather loosely. What exactly does a project mean? What are the characteristics of a project? Well, very simply, but in a way also very importantly, complex is this definition. A project, first of all is a unique venture. It's something we've never attempted to do before and I can't emphasize that point enough. We're exploring new ground, new territory something that hasn't been accomplished or attempted to be accomplished. It has a defined beginning and an end. That also is a unique feature of a project in the sense that projects start, they run and they stop. They're not a redundant, repetitive type activity. If I work for an organization, for example in their finance department and every quarter we run quarterly statements of our financial numbers, it's a repetitive redundant kind of activity that's taking place. On the other hand, projects by definition start, they are run, and then the end. Another component of a project is this idea that they're done by people to meet established goals. So another way to say this is a project has to be more than simply a broad generalization of something like we need to improve our operations. We need to fix the efficiency. We need to improve the order entry system for how we order new parts or replacement materials. That's not good enough. A project needs to specify some established goals. It needs to say we need to create a new system or a new software process that will improve order entry efficiency by 5% over the current year to year processes that we have in place. Something like that at least becomes a bit more defined because it gives some more established goals. And lastly, but also equally importantly is this notion of constraints. Now, I use the term here, you can see within parameters but another way to think of parameters is to think of them as constraints. We only have so much money to spend so we have a parameter of cost. I'm gonna give you a budget for your project but only so much. We have constraints of time. You can't do this on and on and on. It has to be done within a month or within a quarter or perhaps within a year. Who knows? But it has to be done within a timeframe. Another parameter is quality. There's an expectation that the project, when completed, will have a certain functionality or quality that meets expectations. We can't create something that doesn't perform the way we expect it to. And finally, that leads us to this fourth parameter, customer expectations. Please remember, all projects are done with a customer in mind. There's always a client whether that customer is internal to the organization or that customer is some customer outside of the company. Maybe the buying public at large or maybe the government, who knows? But there is a customer. And so every time we think about a project we have to remember that we're looking to improve cost, schedule, quality, but also we want to satisfy customer expectations. You can't do a project well if you're not keeping your eye on all four of those criteria. So what then are some of the elements of a project, along the lines of what I've just talked about? Well, first thing is this idea that projects are complex. Complex is another way sometimes, not always, but sometimes it's saying complicated. There is a lot of moving parts, if you will. There's a lot of pieces that have to work together that have to come together or be interconnected for a project to succeed. As I said, they're one time processes. We do them, we finish them, we move on. Projects are also limited. Those ideas of budget, schedule and resources. I'm not gonna give you everybody in the company you need perhaps. Maybe I can only afford to give you two programmers for that software project. Maybe only one. How are you gonna make this work with limited resources? Projects have to resolve a goal as I said a minute ago. What's the project about? What's the goal? Vague goals nebulous ideas aren't helpful here. We have to know. And more importantly, everybody in the project has to know. This is a major failing sometimes with projects is that some people know the goals. Some people think they know the goals and some people have absolutely no idea what the goals are. They're just brought into work and it doesn't work well that way for project success. The idea, as I said a minute ago, customer focused who is the customer? What's your goal here for making sure the customer gets what the customer wants not what we want or think the customer wants. So some of these general characteristics then based on the definitions I've given you and some of the pieces that we've pulled apart here about what a project is, what does that then suggest for us in terms of some general project characteristics? Well, one idea is a very interesting one and I want to touch on this a little bit is the idea of it's an ad hoc endeavor. It's something we just, we create. It's not part of our ongoing processes. We come up with it. So it's something we're going to do now that's different. That's perhaps creative but it's not what we've done before. And it goes to this point of a clear life cycle. Now, life cycle is an important idea and I'm gonna touch on this here briefly but I'm gonna return to this theme a little bit later in this lesson because it's so important. Projects have a life cycle. They have a start. They have where most of the work is being done, they have a completion. That's unique that sets them apart from so many other organizational operations because they're defined by this idea of a life cycle. And because of the life cycle, much of the work we do on our projects is also constrained by the kinds of activities that have to be done at certain points in time. We use the term projects are the building blocks of organizational strategies. Now, another way to say that is to put it this way projects are the way that an organization operationalizes their plans. So for example if an organization says, our new strategy is to emphasize greater customer support services as opposed to our old process whereby perhaps we were more involved in products themselves. That's fine that sounds good as a strategy. But the question becomes, how are we gonna do that? What is going to allow us to emphasize customer support services? Well, that's where projects come in. Let me give you an example. Rolls Royce and GE are two of the largest jet engine manufacturers in the world. Between the two of them they control a massive amount of market share for jet engines for both commercial and for military use. Some years ago, both companies realized that the technology now would allow them to become not just the manufacturer of a jet engine but also to maintain total life cycle servicing of that engine. So now when an engine is produced by a GE or a Rolls Royce, or a Pratt and Whitney, they install, the engine is installed. But all the very sophisticated monitoring equipment for each individual engine is sent to those organizations and they have rooms, they have people that are constantly monitoring the health of the hundreds and indeed thousands of engines that are powering aircraft all around the world. Now, the ability to do that, to create the kinds of monitoring equipment and then to sell these services to the airlines is an example of a corporate strategy that was operationalized through these very interesting, unique, and very valuable projects they're undertaking. So you see my point is that it's one thing to create a strategy but when we get beyond the what, what is our strategy supposed to be and get to the how? How are we gonna actually make that happen? That's where projects come in mind. Projects then are responsible for just about everything that's new, that's improved. Every new product, every new service that an organization does. Every internal process it develops. When you think about this in your own organizations or those of you who are listening and thinking about how you've seen projects take place in your own unique settings think about it in those terms. What has been done in your organizations from a product or a service or a process improvement point of view? And think back to the origins of that. And you're probably gonna find a project. Projects provide a philosophy, more than that, there is strategy for the management of change. How does change occur in an organization? There are a lot of companies that were very successful a century ago that no one's ever heard of now. There are a lot of companies that were successful 30 years ago that no one's ever heard of now. Because you see at some level and in some way they lost sight of the criticality. The critical nature of change, the need to change in order to stay ahead, to stay on top, to stay profitable. Projects are the means by which we can create these sorts of philosophies or strategies for the management of change. Another unique feature of projects is this. When I was working in my organization I worked in, at one time, I worked in finance. All I dealt with were other financial people. I dealt with finance people in different divisions different parts of the organization. But the point is, I dealt with people in my own background. So if I was in finance I was in finance and those were my concerns. Now, the unique thing about projects for most of us to understand is that projects, many, many organizational projects create a project team composed of people from vast and diverse functionally different backgrounds. So in the same projects, I may have two engineers. I may have an accountant, a marketing person, a production and operations person, research and development scientists, many, maybe many multiples of all of these people on the same project team. And they come at it from very different perspectives because they come at the project from very different corporate backgrounds. And the unique feature here is that it took the project to bring all these folks together, to bridge those functional boundaries and get us all working together. The good news also for some of us who maybe are getting a little bit nervous perhaps about some of what I'm saying is just how new and different and unique projects are is let's understand. We still do need to apply some pretty traditional management tools to managing projects, which is good news for all of us. We have some skill sets. We just need how to understand them and apply them within a brand new context, which is the project. So in our lessons, we're going to be talking about how do I make use of planning and organizing and controlling a project? How do I use these management tools in the unique setting of running a project? That's going to be an interesting challenge, but that's also going to put some, some very specific guidance to this course because we're gonna move beyond sort of the theoretical and get very, very specific into how to. The goal of projects, I alluded to this before, but it's such an important point that it really can't be emphasized too much. The goal of projects is satisfying customer requirements. We're all about trying to find solutions. We have customers we have people who need the results of this project. We are the solution people. We're the ones who are creating that solution for them but we have to do it within certain bounds. We can't just spend money like we're going crazy. We can't just take as much time as we feel like taking and we certainly can't let the quality side of this slip as well. We are the solution makers but we're the solution makers that are working under a discipline, and that's a very important point. Last characteristic is projects, and that's good news. Sometimes some of you might argue with me and said I've been involved in some projects and they seem like they were never going to end. I submit those were bad projects. Those are projects that have been allowed to spin out of control. The fact is projects should remain in control. They should be set up in such a way that they start, they run, and then they're terminated. We move on after completion.