Mackenzie Kyle

What is a Project Anyway?

Friday, April 24, 2009 by Mackenzie Kyle

 

Let's do an experiment. I'd like you to answer this question: what is a project? I'm not asking in the sense of "Do you know the official and correct definition of the word?" I'm asking what you think of when you use the word project. Take a moment to think about it and write it down. Now go ask one of your colleagues to do the same thing. Put the two pieces of paper side-by-side and see what you find.

You will almost certainly see that you will have two different definitions of the word. Talk about them for a moment and you'll probably find that you can agree that you are talking about the same thing. One of you may have something like "A series of tasks the produce a change." The other might have something like "An objective that has to be achieved." Different, but not that different, right? Not exactly. You'll find the definitions range from "A task," all the way to "An Objective", and while one usually implies the other, these are two very different things.

You can repeat this experiment with random people you meet on the street (I'd recommend you don't because people will tend to give you odd looks and shuffle uneasily around you without speaking) and if you ask 10 different people, you'll get 10 different definitions of the word. Again, with some discussion you could probably agree you're talking generally about the same thing, but you can't ignore the fact that the definitions are different.

Now ask yourself another question: what might happen if a group of people is assigned to work together on something called a 'project' and they all come to the table with a slightly different understanding of just what a project is in the first place? One person is thinking s/he needs to define some tasks they need to do in the next week, while another is entirely focused on trying to understand the objective they need to accomplish and sees no value in talking about tasks yet.

To make matters worse, what if these people don't start off by first agreeing on a what a project is before moving on to tackle their specific assignment? In a word: conflict. Not necessarily out-and-out, in-your-face, fisticuffs conflict, but a subtle, slow-burn-frustration kind of conflict. The kind that leads to irritation and dis-engagement. And frustratingly for the people on the team, they won't really understand why the conflict exists. They often think they have an issue with their colleagues' interpretation of the current assignment when what they're really struggling with is the underlying process by which they will work together to accomplish the assignment.

When we don't share a common language, a common process, and common tools, the best intentions in the world are not enough to create success. In my experience, we too often make the assumption that we're working from a shared understanding of how we'll tackle a 'project', without ensuring that we first understand the process by which we'll work together. When things start to go wrong, there is no way to address the issues if we don't have an understanding of the causes.

Next time you're invited to join a project team, start by agreeing on the overall process before you tackle anything to do with the specific assignment.

Comments:

Tuesday, August 18, 2009 - 02:45PM GMT | Sandra Daw
I concur with you Kyle Before commencing on the "project", your team must start by agreeing on the overall process before tackling the specific assignment. I found this read on how to run successful IT Projects in 2009 and common project failures 1. Meet business needs. Every IT project must accomplish a business goal or risk becoming a wasteful boondoggle. Poor communication between business and technology groups complicates this simple concept inside many organizations. If the business side routinely criticizes your IT team, get together and ask them for guidance. While isolation brings failure, discussion is a true harbinger of success. Conversation with the business is the right place to begin an IT improvement program for 2009. 2. Innovate. Conversations with the business should help both sides work together with greater creativity and flexibility. Adaptability is fundamental to survival, especially in tough economic times, so being ready to accept change is prerequisite for success. Although listening carefully to user requirements is the first step, being self-critical as an organization is also necessary. Great things happen when IT embraces a culture of continuous change and improvement. 3. Be honest. Denial is the handmaiden of failure and a leading cause of project death. Change is impossible until a team accurately recognizes its own weaknesses. Having done so, the team can take remedial measures that shore up weaknesses and support strengths. Objective self-appraisal is the hardest item on this list to accomplish; few organizations do this well. Related: Denial: The secret IT killer 4. Align vendors. Virtually all projects involve the IT Devil’s Triangle: the customer, technology vendor, and services provider. As I have previously written, “These groups have interlocking, and often conflicting, agendas that drive many projects toward failure.” Given the great importance of these relationships, success depends on managing the vendors to your advantage. Use contractual incentives and penalties to ensure external vendors operate with your best interests in mind. 5. Arrange sponsorship. Many IT initiatives go across political boundaries within an organization. For these reasons, gaining consensus among participants and stakeholders is sometimes hard. Since problems inevitably arise, a strong executive sponsor is a critical success factor on all large projects. Make sure the sponsor fully understands his or her role and is committed to active participation. The best sponsors care passionately about the project’s goals. Conversely, sponsors who don’t play an appropriate advocacy role when needed can kill an otherwise healthy project. These five points cover relationships between IT and its environment, which includes internal stakeholders and external partners. It also addresses culture and process, bringing together essential ingredients to overcome many problems that plague IT. I would welcome further reads on this topic and hope am able to attend the proposed "Understanding Project Management" course this fall Thank you, Sandra Sandra Daw, Regional IT Liaison MCSE, MCP+I DIRECT 250.979.2570 PH. 250.763.8919 FAX 250.763.1121 CELL 250.863.6672 600 - 1628 Dickson Avenue Kelowna, BC V1Y 9X1 sandra.daw@mnp.ca mnp.ca

Add A Comment:

Anonymous
Required  
http:// (Optional)
 
Protected by FormShield
Refresh
Listen
Please enter the characters shown on the image
  Enter the text from the image above. (Required)