Leadership

Is your project a real project?

Projects are a powerful tool for selecting work, motivating staff, aligning technology with business, and building client relationships. Paul Glen lists five important features of projects that distinguish them from other forms of work organization.

I often hear the phrase "project management" used interchangeably with the word "management." That's ok, since everything that we do is a project...right?

Well, no. A great deal of the work that we do isn't organized into projects, even if it could be. And that's a problem, since the project form of work confers a number of important benefits on the organizations that do them, and the people who participate in them.

Projects are a powerful tool for selecting work, motivating staff, aligning technology with business, and building client relationships.

Here are a few of the important features of projects that distinguish them from other forms of work organization.

1. Unique output. Every project produces a product, a product that's unique. Other forms of work are designed to carry out repetitive tasks or mass produce identical output, but projects always focus on building something that's one-of-a-kind. 2. Conscious constitution. Every project must be started with explicit management decisions to invest time and resources. Projects never just start. They never spontaneously generate. A decision must be made to create a project team to build the unique output. 3. Time boundaries. Projects have distinct beginnings and endings. Most other forms of organization are designed to endure and self perpetuate. Project teams are assembled based on the conscious decisions of managers and should be disbanded at the completion of their work. Otherwise they become departments or committees that attempt to live on after they have delivered their value. 4. Specific goals. Well-managed projects have clearly articulated goals that explain what problem the project will address or opportunity it will exploit. Many other work structures are designed to carry out tasks rather than to achieve a goal, but tasks may or may not contribute to the success of an organization.  It can be tough to tell whether a set of tasks is actually valuable. Goals on the other hand are much easier to evaluate. 5. Change focus. Every project is focused on creating some form of change within an organization. Technological projects are usually focused on changing the way the people work or the products that they sell. Very few projects are initiated to maintain the status quo. So every project must account for the human responses to the changes they plan and implement.

So when you are planning work or organizing people, think carefully about whether you are building a real project or whether you are creating something else.

16 comments
philr
philr

Knowing what created the need for the project in the first place is valuable information. Assessing the internal politics and standing of the initiators is also key. Sadly well-conceived projects with demonstrable business value may fail if the initiation is stuffed and those with influence are not involved. Poorly conceived "projects" may get traction if the sponsor gets carried away with enthusiasm. Of course many companies are truly customer and business focussed and do not suffer from internal politics... long may they live on... and probably will. One project I proposed took 8 years before it got off the ground. The politics had changed in the interim. I agree overall with the points made. I have seen "projects" running that were not. As an IS/IT manager I terminated one such when I took over. Achieving this was a saga due to selling job that had been done before I arrived. (The supplier went bust a year +- after we exitted our contract. I had applied CMM criteria to them as best as I could and with judious questioning and knew we had to get out.) Another "project" had spent $50m and rising. Concerned by the poor state of it, I produced a document making similar points to the above. It was squashed by internal politics. I was an external consultant I did get paid!

ahmedkamel100
ahmedkamel100

Projects are subject to change. Although inconvenient, however it is matter of fact the PMO has to deal with especially if the scope is not clear enough or hasn't been planned well prior to starting the execution. However, there should be an approved process as part of the overall "Governance and Control" for "Change" with a "Request Template" stating the reason , area of change i.e. scope, time or cost and its implications on the project itself (scope, time, budget and quality) and other dependent projects, signature and approvals area according to an agreed "Signature and Approval Matrix", and version control number to be able to archive and track when needed. Best Regards, Ahmed Kamel

PMPsicle
PMPsicle

Why can I never leave well enough alone? This was an excellent list as it stands but I have one disagreement. I disagree with Item 5 Change Focus. Not all projects are focused on change. Change can be either a direct product, an indirect product or an unintended product. Or it may not be a product at all! About 90% of my projects are change related but that's because most of my projects are either IT or Strategically focused. Both of those types are normally concerned with implementing change. However, a number of my projects are marketing related. They meet all the requirements for being considered a project; they are run as a project, and they have a fixed start, end and product. However, they do not involve change (unless you consider changing the prospect into a customer -- but strictly speaking that's outside the project scope, it's part of the product scope. And is never certain.) Other than that a good list ... even if some of the terms were misunderstood. Glen Ford,PMP http://www.TrainingNOW.ca http://apps.learningcreators.com/blog

amusallami
amusallami

Thanks Glen, Adding one very important success factor that is "Sponsorship", I'm saying his because I understand very well the suffering with out a proper sponsorship from management to support your project, then you'll start to loose your resources, focus and priority ... which is most likely to happen on organization internal projects when it is put in competition with external projects (chargeable)... Good luck. Ahmad Al-Musallami

mkennedy2107
mkennedy2107

Your point # 5 should be your focal point. "Projects" occur to facilitate / accelerate change. Defining the problem is often the ultimate gate to change. Point # 3 is actually incorrect. Projects are actually transitions, moving from one process to another. There is no end, and you need to transition with a transition. The objective becomes to define what tasks need to be accomplished, then determine the path forward. The desire to "end" a project (and keep the work from becoming a "failure" or sunk cost) should be to recognize or plan for that day when either the problem has been solved or that additional tasks are required. This is why dates "slip."

phil
phil

I think that pretty much covers it except for one thing ... I recently started as a project manager where, historically, projects had all of the five attributes that you identify but there was no identified "customer" for the outputs. The project team ended up owning and maintaining the products, which not only drained resources and affected future project delivery, but also meant that they were not used/promoted within the organisation. Unsurprisingly, this ended up as a successful attempt at dust gathering ... One of my objectives is to change this and make sure that all products are handed over properly, once the customer has signed them off as fit for (their) purposes.

richardp
richardp

Thanks for pointing this out Ahmed. Aspects for change management play in important role for project life.

AppDevGuyFromTX-21702053807677063493239650930425
AppDevGuyFromTX-21702053807677063493239650930425

IT projects very often are transparent (or should be), to the business. Development teams usually emit a collective moan when it is realized that a system change will require business/users to change the way they do things, since that's typically much harder than totally rewiring what's under the hood. Case in point: Y2K Compliance, the project that turned "PMO" into a household name. Making systems Y2K compliant was most definitely an IT project, but for the most part it had zero impact on business practices and did not result in a unique product, unless you consider entering a 4-digit vs 2-digit year to be "unique product" and a change to business practive. In the applications development world, size does matter.

PMO Weasel
PMO Weasel

Agreed. A project needs initial sponsorship to develop and set the charter, but also needs ongoing representation from the Sponsor to keep engagement and focus. The PM's authority to direct resources effectively ends when the Sponsor withdraws, or is perceived to have withdrawn their support.

PMPsicle
PMPsicle

Sorry but Point #3 is a key definition to defining projects. The basic definition of a project is: 1. Specific and unique product 2. Specific start 3. Specific end Yes, IT projects are OFTEN transitional in nature. But not always. If you are working for a software company, you are producing a product. Now the product may create change (hopefully improving your customer's life) but the project may not be focused on change. Especially if this is the first release of the product. Changes the customer must make are strictly their problem. Projects are not transitions. They may need to include transition (that was the point of number 5 Change - which I disagree with for reasons I state later in the thread). However, the project itself is not a transition. If it was, then the concept of agile project management would have no place in the world. Why? It is start/end (i.e. budget/time) focused at the expense of scope focused. All projects would be Waterfall focused (i.e. fixed scope). In the real world there is a place for both scope and budget focus. And in most cases, there is a balance that must be struck. Even in agile there is a need to deliver something useable. And in Waterfall a need to stay within budget (plus). There are very few situations where a solution must be developed whatever the cost. By definition, all projects must end ... otherwise they are operations (aka processes). Glen Ford,PMP http://www.TrainingNOW.ca http://apps.learningcreators.com/blog

phil
phil

Whilst I agree that projects are transitions, they should not be part of a general continuum. I prefer to think of projects as providing a step change rather than a smooth transition. In a way, they are the revolution that fuels evolution! Ending a project is essential to it remaining a project otherwise it becomes "business as usual", and, in that sense loses its tangibility, which, in turn, means its success (or failure) cannot be measured. If a project fails (within the agreed timeframe) to deliver the solution to the problem, I would not consider it an option to let it "slip" because that is when things can go very wrong. It is better to end the project, review what went wrong and then either start a new project based on any lessons learned or modify the original project boundaries, agree new dates etc and then continue. A project may form part of a larger programme, in which case it will be a "transition with(in) a transition", but it must still remain a distinct entity. That said; programmes, too, must have an end.

a.barry
a.barry

handover is key. In most cases, this means that an internal customer (not just a sponsor) is needed. If the project is for an external customer, some arrangement has to be made for support later (so in a sense the support department is the internal customer). I've seen cases where a project was done for an external customer with no provision for support. Years later the dreaded call comes in (some OS upgrade broke something) and a "swat team" is hastily assembled, relying only on the documentation (which was never read by anyone) who attempts to fix the problem.

mkennedy2107
mkennedy2107

The concept of definition as a discrete process was advanced by Rickover (and others) because submarines were completed. However, the technologies developed to complete the project (along with the workers and managers who participated) do not simply end and go back to work where they were. I won't dispute the use of the "step" concept, but too often, the implementers treat the project / transition as if "when it ends," we go back to where we were. The model is not a bell curve. If, in fact, you use the step model, you transition from level "x" to level "y" (or at least x'). The "definition" from the last millennium is not accurate. Failure too often rests on this definition, and too often causes the slip.

richardp
richardp

My boss on a past consultant team regularly reminded us for the importance of "deliverables". These tied with stated goals which added value to the project and justified our work.

minstrelmike
minstrelmike

I like the idea of clearly defining a project, but like most everything else, it has a fractal boundary that gets hard to define the closer you stand. The article made me think of gardening/landscaping projects. When I _build_ a new garden, that is a project. However, once it is done and the main plants and rocks in place, there is still regular weeding and mulch replacement and occasional plant replacement or reseeding. That's on-going maintenance and not any sort of building-a-garden project.. Sometimes, I will remodel an existing garden. Replacing a single plant seems like maintenance. Replacing 2 or 3 or 5 plants starts seeming like a project again, requiring more planning before starting and there will be definite end times and goals. But that is also true when replacing a single shrub.

bengt.lyng
bengt.lyng

I very much agree with Phil underlining ending a project as essential. I would like to focus on the handover - having experienced projects which de facto never seem to be taken over by the organization which it?s supposed to be delivered to. As time goes by, resources and competence in the project group ?disappears?, thus leaving the organization with a new feature or system they are not prepared to handle. The result may often be the project delivery not accomplishing the project goal. So ? focus on ending a project are important, not least to make the organisation aware what?s coming, and empower them to take over responsibility.

Editor's Picks