Project Management optimize

What advice would you give a new IT project manager?

TechRepublic is asking veteran IT project managers to share advice for newbie PMs. Please post recommended skills and resources and what not to do in this project management discussion.

Experienced IT project managers, what career advice would you offer someone who is just starting out in project management? For instance, what skills do you think every project manager should master? What are the rookie mistakes that many project managers make when they're starting out? What books or online resources would be invaluable for a new PM?

Basically, what do you wish you had known when you were learning the ropes in IT project management? Please share your words of wisdom in this discussion.

About

Mary Weilage is a Senior Editor for CBS Interactive. She has worked for TechRepublic since 1999.

24 comments
falisalaam
falisalaam

My best advice: be an active listener; and use the talent around you.

tesha29
tesha29

lack of clear planing & team understanding

Graic
Graic

communication and getting in touch with all the IT staff. not to rush things first. understanding the need of the project. and to start from where necessory

LogicalConsultants
LogicalConsultants

Ask your development team for estimates, but keep in minds developers often (unconsciously) tend to be optimistic with work they want to do, and pessimistic with work they don't feel like doing. Use automatic tools like ProjectCodeMeter, COCOMO and SEER-SEM to get some objective and statistical results - the truth is somewhere in between.

denisanderson07
denisanderson07

Make sure you are very clear about project requirements and the goals to be achieved. Everyone working on the project should be updated about the progress, risks and issues routinely. Check on the BCWS, BCWP and ACWP and update everyone in a timely manner. Proper task notifications and what-if analysis are some important aspects to consider while managing a project. Appropriate selection of a [url= http://www.microsoft.com/project/en/us/try-buy.aspx] project managing software [/url] is critical to efficiently accomplish these tasks. One of the best software for project management out there is Microsoft Project 2010. Features like the Gantt chart, inactive tasks, automatic project scheduling according to the changes made to the task, and easy collaboration with other open source software help to efficiently complete assigned task in time and with precision.

mlonghouse
mlonghouse

1) There is no silver bullet to what PM process will work best across and within specific organizations. I've seen large organizations with 15+ steps in the PM process and small organizations with undocumented 5 step processes. At the end of the day, the one right for the team is the one they are able to manage efficiently and effectively. 2) All PM processes should mature over time as businesses or staff members change so you need to be able to adapt and recognize what's working and what isn't. If the process is missing steps, fill in the gaps, if the process has too much overhead, remove steps. Don't be afraid to question or change it. This should be part of your post-project analysis to see what went well and what did not. 3) The basics of project management are pretty straightforward, the details are where projects can fail. Assumed requirements, incomplete work-task breakdown, side meetings between project sponsors and other team members, lack of buffer in project for a few minor missed requirement, fear of reporting status if the project is behind or at risk, etc.

Douglas_DSilva
Douglas_DSilva

Be honest to your boss as well as to cliet. Always set achievable expectation and motivate team to attain the Goal.

Hugo J
Hugo J

I would say that the most common mistake I have seen in IT projects is bad management of expectations from the various stakeholders. And I mean the outspoken as well the hidden ones. Expectations from the business side and from the IT side. When these expectations are not well managed I have seen solutions delivered that are not accepted though they from a technical point of view are according specifications. By arranging workshops and other ways of communication with the stakeholders and by listening twice as much as speaking a new IT PM can start getting it right.

Neil Leacy
Neil Leacy

For many people common sense and project management are like oil and water; never the twain to mix. Use your common sense as much as PM methodolgy to control your project. Is your project a quick-win, short term project or a roll-your-sleaves-up, heavy duty long term project? Which one will not require you to follow as much of the suggested PM practices as the other? Communicate to all people involved in simple terms and always explain why certain things need to be done in a particular way; a lot of people look up on you as an instigator of more paperwork rather than just letting them 'get on and do their job'. Just make sure they do understand and are not left feeling bamboozled by buzz words and acronyms. Cheers, Neil

bergenfx
bergenfx

Absolutely impossible to respond to this concisely, but with two shakes of the brain, this is what rose to the top. Integrate early and integrate often. Whether you follow iterative development, or want to call it agile or even if you find yourself engaged in a massive two year waterfall project, set frequent integration points. Unit level development is fantasyland until it is forced to play well with the other components. This gets developers in touch with reality and greatly influences the forward path of development. It also helps to keep developers on track and motivated, knowing something has to work in two weeks, instead of three months. It also gives an opportunity for a requirements sanity check -- requirements analysis is not frozen in granite before design and development, but is best subject to refinement (and re-negotiation) during development. Common, shared vision. I don't care how gifted your team may be. If there is not a common understanding and a common purpose you will not deliver ??? at least, not deliver the right thing. The responsibility for this really rests up the management chain, but you need to carry the vision and create the unity. If that vision is not properly defined from your managers, you need to take the bull by whatever you can grab and define it yourself. This goes way beyond the content of a project or deliverable into spirit of unity for your team. Aggressively manage scope and change. Requirements are the cornerstone of a project. They are bound to be fuzzy and subject to broad interpretation and continual piling on of meaning and functionality. You have to deliver what is needed from both voice of customer and innovation fronts, but you are also vulnerable to scope creep steamrollers. You need to master triage, negotiation and head-strength. Managing this is the darkest art in the dark art of project management, (Project certification bodies are clueless to this). Don't forget to manage risk; it will pay off to know what is bearing down on your delicate tail feathers. Risk is not a one time discovery, nor is a "risk event" a one-time happening that just decided to explode. Risk is an ever changing, developing landscape. Not to sound paranoid, but "they are out there," and it is better to know who they are, the threat they impose and what you are going to do about it when they are about to make your day a bad one. Most important, remember you are in service to those doing the real work. They deserve your support and your dedication to their fulfilling their work.

Notdub
Notdub

First, do not let the requestor or sponsor bully you into either a fixed cost or fixed time frame. If you hear the phrase: "We have $xxx amount of money, and we want you to put in xxxx system" or "Here is your budget, now develop the project to make it happen" or "The owner wants this up and running by xx/xx/xxxx date" Then run away! Any time you are given a budget or time frame that someone decided on without any facts, research, due diligent planning, etc. you are doomed to failure. As the PM YOU are the one who figures out what is needed, how much it will cost and how long it will take...it is NOT your job to squeeze Project A into budget or time frame B just because the boss has that much money or wants to publish a press release on that date, etc. All projects have a ???true??? time period and a ???true??? cost factor! You tell them how long that project will take, and what it will cost, and let them decide if they want to do it. And second...avoid the situation where you have to rely on a series of back to back to back best case scenarios in order to make a deadline. For example, your project involves: 1) adding a cooling system to a data center, which would require 2) some kind of City or County building inspection permit??? 3) followed by an outside vendor installing, configuring and testing equipment... DO NOT do this: "Well, the contractor says they can probably slam in the new cooling unit in two weeks if nothing goes wrong...and the City has an inspection process that takes from 2 to 6 weeks...and assuming we pass inspection the first time we won't need a second inspection...and the vendor says that if all their equipment comes in on time and their install crew is available, they can have the system up and running in 1 to 2 weeks.... So, that would mean 2 weeks for construction, 2 weeks for inspection and one week for the vendor, so let's lock in the project timeline to 5 weeks and plan the launch, press release etc for 5 weeks, that should make the owner happy and maybe I will get a bonus!" You are relying on: a) A contractor being able to complete their work in their self-estimated best case scenario time frame. NO offense intended to contractors, believe me....but I think most of us have had the experience of construction dates 'slipping' for one reason or another... b) The City to get to your inspection right away, and your items passing inspection the first time. Ask yourself; what are the odds that a City department is going to put ME at the top of their list....and that any given construction project is going to be done 100% correctly the first time? From my experience, the chances of either one happening are absolutely zero. c) The vendor to not only have their parts onsite on time...but also you are planning on them having the correct staff available to do the work the moment you are ready...well, what if there IS a delay based on the construction or inspection examples above? Can the vendor's installation team come out whenever you are ready, or could they have been scheduled at another site due to your delays? And once they get there, what are the odds that everything, i.e. hardware, software, configuration, data imports or customizations, etc. are going to go off without a hitch? Bottom line...RESIST THE TEMPTATION TO ASSUME EVERYTHING IS GOING TO GO RIGHT!!!! And instead, PLAN ON EVERYTHIGN GOING WRONG and make provisions for problems, have backups, have "flex time" built into your schedule to absorb delays, etc. And most importantly, if possible...plan your time frames based on EVENTS, not DATES. Example: 1) Construction scheduled to start March 1 and take two weeks. 2) Inspection process will take approximately 6 weeks and will start AFTER COMPLETION OF THE CONSTRUCTION. Do NOT set a specific date, but a time period after the successful completion of the step before it. 3) Installation scheduled to take approximately 2 weeks, starting AFTER RECEIVING BUILDING PERMIT, the specific start date pending availability of the install crew. Again, don't plan on a date when you will get your permit; plan on starting the install AFTER you get the permit, whenever that is. By scheduling based on events and not dates, you can shift your plan easily by filling in milestone completion dates and calculating the remaining time frames based off that, rather than having to recalculate every calendar date for every event any time one slips. Good luck!

PAexec
PAexec

Beyond the obvious - be honest, work hard etc., there are no real "silver bullets". Excellent PM's come in many flavors - You have to develop your own flavor based on YOUR strengths. If you are truly blessed, you'll work for or near one good manager whose style matches yours, and there is no substitute for that. If not, observe good PM's in action, and try to establish what you would do in the same situation - the good and the bad... You'll develop your own style soon. Remember as in any "management" situation, there is no right answer - you have to manage. Good Luck!

thekaps
thekaps

For me communication and honest expectation setting about deliverables will pave the way for a few bumps down the road with stakeholders and the business community. Your reputation about being an honest person is very valuable when obstacles hit the project.

tkrol1
tkrol1

Embrace Change as it is inevitable in all projects. Learning to manage change well will enable you and your teams to succeed.

Tigger_Two
Tigger_Two

Especially when I am coming into a project already in flight, I like to ask the team, the sponsors, and the stakeholders what they think we are out to accomplish. I get different answers from all of them, generally, but it tells me what and where the inevitable disconnects are. After that, the task is to get everyone back onto the same page. There has been a cartoon around for years showing the design of a swing in a tree drawn several ways. You can find a copy here: http://www.soloseo.com/blog/2007/11/03/what-the-customer-actually-wanted/ Better than anything else I have seen, this really clarifies how disconnect can impact a project and thus insure that you will fail to deliver what the customer (business) wants. Even when everyone is managing to the written plan, it is possible and even probable that understanding will shift. Regular checks with business, stakeholders, and team will insure that everyone continues to see the same goal the same way. Edit: formatting

Shankarl
Shankarl

Though evry one says listen to your people and understand them, I a dvise you use your common sense and add analysis and take decisions. Example: You have good developers and all work well. If they all say, we can complete this module by end of Next week. At the end of the next week work is 80% completed. Whom to blame project manager or developers. Only PM !!! They told in their perview of knowledge. It is your responsibility to judge and match against know constraints and un known constraints(Risks). Good luck

PMPsicle
PMPsicle

Well maybe not but certainly well up there ... Watch the politics ... the way people work together will make your project succeed or fail. So you need to keep a close eye on how people are dealing with each other. Especially if you are coming into a project after the fact. Hidden agendas and people trying to forge alliances have sunk more projects than any other source. Also way up there ... Keep in touch. Identify everyone you need to be talking to and be sure to drop in to shoot the breeze with them. Give them enough information so rumours and lies are always confirmed before being believed. Get them talking and then shut up. Listen -- not just actively but voraciously. Finally ... Practice honesty. Always admit when you screwed the pooch. Always take the blame -- don't try to shove it off on someone else. If necessary don't identify who was at fault just the mistake and how you and your team are trying to fix it. Getting people to trust you is 90% of the battle.

Tony Hopkinson
Tony Hopkinson

Change is a given. Project management is not a popularity contest, if the plan becomes wrong, change the plan, not the project.... Sounds obvious, but most unsucessful PMs fail, when they can't find some reason why it isn't their fault.

michelle.morris
michelle.morris

Do not let yourself become the department admin. Make sure everyone understands your role and does not push off administrative tasks onto you. Your job is to ensure that tasks are completed not complete them yourself.

David Stratton
David Stratton

The single biggest factor in the success of projects that I've been on is an obsessive desire to limit requirements. The absolute first thing you need to determine is what business need needs to be met, and for every single "Hey, can the system do this?" question that comes up, force the asker and the decision makers to explain why that "feature" is absolutely necessary to meet the final goal, or how the time/risk involved in adding the feature is outweighed by the benefit of the feature. This approach weeds out a lot of dumb ideas, and results in leaner, smoother processes and products that "just work" the first time. Every additional feature is just one more thing that can go wrong, so be vigilant in ensuring that whatever system/product/process you're working on is no more complex than it needs to be.

sneemkerry
sneemkerry

Communicate! Communicate! Communicate! Ensure that all stakeholders are kept apprised of progress, risks and issues routinely. Over communicate on big issues that are being worked on. When leaving status voice mails or emails on major problems that are being addressed, tell your audience when you will provide the next update. That will set their expectations and, hopefully, reduce the phone calls you receive requesting status.

tech
tech

With all the science for project management hanging around your neck (think PMBOK), try to remember that successful project management is really an art, not a science. It is the art of managing others to get them to do what you know needs to get done. It doesn't matter how well you know how to track requirements, manage risk, etc.; it's about how successful your team is against the goal before them. Use the (scientific) tools to your advantage, not as your hammer.

sankalpw
sankalpw

When you start making changes to the existing processes or introduce fresh new processes, please make sure that you plough them into the system in as non-intrusive a way as possible. If this means that you have to introduce these processes one at a time, or to one department or team at a time, do it that way. But whatever you do, do not directly splash into the comfort zone of the people since the resulting ripples will mostly wash you out of the system.

michelinus
michelinus

Ensure you have thick skin, double check all details, hone your communication skills, be wary who you trust, plan and plan again...and smile.