Pages Menu
Categories Menu

Posted by on Aug 13, 2015

IT Project Management Theory vs. Practice

IT Project Management Theory vs. Practice

ContractA question that is asked in many of my seminars is:

“This is fine in theory, but what about practice: how do you manage IT projects in real life?”

This is the fine line between what is being provided by the current “bodies of knowledge” that exist in the project management discipline and what actually works when a project manager has to put together a team and execute a real project. What from the theory of project management actually helps an experienced project manager in managing his/her IT project?

First, it should be understood that the concept of “best practices,” in my opinion, does not exist since project management is not a ‘one size fits all’ discipline. What will work for a commercial banking enterprise will probably not work for a government agency and vice versa. What works for your organization must therefore be discovered as ‘workable practices.’ Begin with so-called best practices, but determine what is working for your organization and do not be afraid of altering these so called body of knowledge ‘best practices’ to suit your needs.

Second, understand what can be learned from reading and what must be experienced in order to be effective in managing your projects. Reading and attending training or seminars is a great way to begin and further your education and understanding of what has been applied to other project environments, but there are activities that need to be experienced in order to make them applicable. Reading how to plan a project, how to write a project charter, how to analyze a schedule, or how to form a team are topics and knowledge that can and should be garnered from reading and seminars.

For example, in our new IT PM Mastery Suite curriculum, we have designed the curriculum to provide what are being used in today’s IT projects, not just what is listed in bodies of knowledge Instructors are actual practicing IT project managers – not professors or career teachers – they are on the front lines applying their knowledge and experience in actual IT project conditions and circumstances.

Third, once you have read and attended your chosen seminars, take the knowledge, and find a mentor with the years and experience that you may lack. Ask them to assist you in improving your professional capabilities in the actual application of the ‘book knowledge’ towards the successful completion of your assigned IT project duties. A mentor is someone that teaches, educates, and directs through their own example and practice; someone that is willing to share what they have experienced with those that will fill in behind them as they move up in their professional career. If your organization does not have an IT project management mentoring program, suggest that they immediately establish one. This will be the topic of our next blog – how to setup and run a successful IT project management mentoring program.

Finally, keep a professional journal of your IT project management activities, assignments, successes, and failures. Learn how to be both self-critiquing and objective about how you are progressing. Those that do not keep a record of their professional career will soon stagnate or worse, repeat your failures without the ability to repeat your successes. Recording what you did and the outcomes of these activities is one of the main characteristics that, in my opinion, separates a true professional from one that is simply ‘doing a job.’ A true professional has the will, the motivation to learn what they did right so that they can repeat it, and dissect what did not succeed so they can prevent themselves from doing it again.

I have kept a journal from each of the 112 projects that I have managed in my 40+ year career, and each month I review four of them (one per week) so that I will not forget what I have done to succeed or not succeed. This keeping of a personal professional journal can be one of your most powerful self-improvement activities if you are objective, honest, and complete in its accomplishment. You will know why you succeed and why you did not. Successes are easier to repeat while mistakes can be avoided.

Thus, the difference between theory and practice is in the implementation by you and how you apply your reading and coursework to improving your stature as an IT project manager. No one can make you a better IT project manager simply by listing or expounding about what is ‘best.’ You have to take these pieces of advice, research them, study them, and then find out what works for you and your organization in raising your project success rates. Take what you read and what you are taught and subject it to your own scrutiny and study to determine how such knowledge can be appropriately applied to YOUR practice – not someone else’s.

Have a great end to your summer, and join us next month for ‘how to setup and establish a successful IT project management mentoring program.’

 

2 Comments

  1. Thank you for this article. It certainly provides some great fodder for dealing with the way in which projects are managed. Sometimes, practice has lots to do with administrative policies and rules and what is ordinary and customary within the organization. The book learning isn’t always applied.

    No, people ought not manage more than one project at at time. It’s impractical to do so, right? Well in the real life, project managers often have more than one project under their belt. I know and even our bosses know that the work cannot be done efficiently and effectively when working on more than one.

    Additionally, in many courses they talk about convening teams specifically for the present project, pulling people from their other work roles based on their areas of expertise. But in reality, the workload sometimes is dumped onto an already-existing team to manage, usually a team that lacks the subject-matter expertise to manage it effectively. I have seen a data management team tasked to manage an IT project. That’s just crazy. They spent more time seeking clarity and explanations, when if they had folks with an IT background, they wouldn’t have had to waste time trying to learn all the terms and concepts.

    The biggest faux pas I have seen regards to a COR or COTR. They should have been given an appointment letter designating the contract on which they’re working; however many a COR/COTR begin the contract work before they receive the appointment letter. That usually comes long after the work has begun.

    These are the items that immediately come to mind. I really do appreciate how things should be done in terms of the current body of knowledge in the industry. But I find, just like it’s stipulated in this article, in practice, things are done sometimes quite differently.

  2. Thank you for your both insightful and detailed comments, Mr. Saunders. I agree with you concerning the issues that you both discussed and are experiencing within the public service arena concerning the differences between ‘theory and practicum.’

    However, remember, change begins not with a shout, but with a calm discussion by those that have the facts and experience on their side. Begin keeping your professional journal, if you have not already, in order to maintain a running record of these difference of what is implemented in your projects along with suggestions of ‘small changes’ that could improve the situation.

    As you rise in your project management career, this will provide you with the professional ideas and alternatives that when you are given the chance, you can implement and verify the hopefully improved outcome. I have worked on many USG projects where showing small changes (kaizen – Japanese) can be acceptable as non-threatening, but with the ability to effect change over time.

    Good luck, and thank you for your reading and participation.
    PH Lohnes, MBA+, PMP, MCTS

Post a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>