1 / 65

Best Practices for Successful IT Project Management

Best Practices for Successful IT Project Management. Andy Pedisich Technotics. What We’ll Cover …. Getting the right start – it’s all about the project manager Gathering requirements that shape the project’s results Selecting and socializing the project

jatin
Download Presentation

Best Practices for Successful IT Project Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Best Practices for Successful IT Project Management Andy Pedisich Technotics

  2. What We’ll Cover … • Getting the right start – it’s all about the project manager • Gathering requirements that shape the project’s results • Selecting and socializing the project • Creating a project plan that gives structure to the tasks • Getting to “Yes” in day-to-day negotiations • Looking at the 5 implementation stages of every project • Making meetings count and, also, not boring • Looking like you mean business • Running around obstacles • Seven strategies for a successful technical project • Wrap-up

  3. What We’ll Cover … • Getting the right start – it’s all about the project manager • Gathering requirements that shape the project’s results • Selecting and socializing the project • Creating a project plan that gives structure to the tasks • Getting to “Yes” in day-to-day negotiations • Looking at the 5 implementation stages of every project • Making meetings count and, also, not boring • Looking like you mean business • Running around obstacles • Seven strategies for a successful technical project • Wrap-up

  4. Who Will Be the Project Manager? • You need to find a project manager • Or you’ll need to turn into one yourself • You need someone to be the project manager • And always remember: • You are more valuable as a technologist and a project manager than as either one of those alone • There are at least 3 kinds of project managers

  5. Type #1: The Total Megalomaniac • This project manager: • Is in charge of every aspect • Projects, tasks, resources, budgets • Often micro-manages each task • Even though their knowledge about the technology is thin • Doesn’t take their own meeting minutes • Reports directly to high-ranking corporate managers • This kind can be valuable to work with as long as you can encourage people to be reasonable with due dates and expectations

  6. Type #2: Just Manages the Project Itself • This project manager: • Usually knows something about the technology being deployed • Schedules meetings • Writes down assignments, tasks, deliverables, and due dates • Takes their own meeting minutes • I like this kind of project manager because they free me up to do more of my work or to follow up with team members who are having issues keeping up • Which means I have more time to “chase down the shiny things” that I really enjoy

  7. Type #3: The Combo PM/Technologist • Project Manager Type #3 is a combination technologist and administrator who also acts a lot like Project Manager Type #2 • The question you need to ask yourself is: • “Can I be Project Manager Type #3 – the Working PM?”

  8. Ask Yourself an Important Question About Who You Are • Can you morph back and forth between being a Project Manager and Administrator? • Is it possible? • Yes, I’ve done it plenty of times • When you take on an additional role, you become greater than the sum of the parts • You can even ascend to a position that deals with projects on a Type #1 Project Manager basis • All encompassing with budgets, schedules, resource management, the works • There is nothing that can’t be learned • You can make it part of your accomplishments for the year

  9. What We’ll Cover … • Getting the right start – it’s all about the project manager • Gathering requirements that shape the project’s results • Selecting and socializing the project • Creating a project plan that gives structure to the tasks • Getting to “Yes” in day-to-day negotiations • Looking at the 5 implementation stages of every project • Making meetings count and, also, not boring • Looking like you mean business • Running around obstacles • Seven strategies for a successful technical project • Wrap-up

  10. Setting the Scope of the Project • Establishing solid requirements is the most important part of any administration project • They represent the “scope” of the work that is to be done • It lets you dictate what will and will not be done as part of the project • My favorite expression during a project meeting … • “I’m sorry. We can’t do that. It’s out of scope.” • There are two types of requirements • Business Requirements • Technical Requirements

  11. Business Requirements Give the Project Logic • Business Requirements tell everyone why you are doing the project • It legitimizes the entire plan • This gives you the support of all levels of management • You need Business Requirements because: • It’s essential to get the budget dollars you need • You need management’s day-to-day support • Management must understand why the project is happening • They need to be shown at a high level • Put together a short position paper outlining how/why the business needs the project • No more than one or two pages • Don’t worry, if it’s longer, it is highly likely that management will only read the first two pages anyway

  12. Keep the Business Firmly in Mind: $avings! • Be sure to include how these requirements will benefit the enterprise • Link these requirements to budget dollars • Savings due to less downtime using clustering • Savings with reduced Help Desk calls due to ID Vault • Savings due to the ability to be more proactive • Savings due to consolidation of servers or other equipment • Storage savings due to DAOS • Reduced costs for mobile devices using Traveler

  13. Technical Requirements • What is the final product going to look like? • What new features will you roll out? • What will the new configurations look like? • What changes will be made to the architecture? • These are all “what do we want?” type statements • The “how do we want to do this” part comes next with the design aspects of the project • Determine features you want to roll out • This is a little more difficult because users don’t know and can’t know the features very well until you tell them

  14. Requirements for Features and Functionality • Technical Requirements are blueprints for the scope of project • They set a baseline that will be followed throughout the project • They help prevent deadly “scope creep” • When project objectives expand beyond what you agreed to • Projects that are not well defined can fall victim to scope creep • Scope creep often results in cost overrun anddissatisfaction for stakeholders, users, and management • Both sets of requirements must be written down to be effective • In this form, we refer to them as “Requirements Documents” and “Design Documents” • Reviewed and approved by management • Reviewed and approved by stakeholders in the project

  15. Don’t Forget to Define “Finished” • When specifying requirements, be sure to clearly state the point at which the project has been completed • This can actually vary depending on the type of project • DAOS and Traveler projects end when they have been implemented • User projects are different than infrastructure projects • User-facing projects, especially user upgrades, might be considered complete when the project is 85% completed • Users might be on leave or vacation and might have to be upgraded separately

  16. What We’ll Cover … • Getting the right start – it’s all about the project manager • Gathering requirements that shape the project’s results • Selecting and socializing the project • Creating a project plan that gives structure to the tasks • Getting to “Yes” in day-to-day negotiations • Looking at the 5 implementation stages of every project • Making meetings count and, also, not boring • Looking like you mean business • Running around obstacles • Seven strategies for a successful technical project • Wrap-up

  17. Selecting the Project • Here is a list of 7 projects you might want to work on: • Upgrade servers from 8.5.1 to 8.5.3 FP1 • Implement DAOS • Implement ID Vault • Upgrade the Notes client from 8.5.1 to 8.5.3 FP1 • Develop a disaster recovery site • Roll out Sametime • Implement Traveler • We have limited resources • Which ones should we do?

  18. Make the Best Use of Your Limited Resources • Here is my list of the projects ranked according to resource needs • Implement ID Vault • Low risk, big payback, put someone in charge – done • Implement Traveler • Big win, low risk, happy Android/iPhone users • Implement DAOS • Relatively complex because it involves rethinking backup/restore, but big disk space win (boring!) • Roll out Sametime • Upgrade servers from 8.5.1 to 8.5.3 FP1 • Upgrade the Notes client from 8.5.1 to 8.5.3 FP1 • Develop a disaster recovery site

  19. How About Projects That Give Users Big Smiles? • Here is my list of the projects ranked according to happy users • Implement Traveler • Big win, low risk, happy Android/iPhone users • Implement DAOS • Relatively complex because it involves rethinking backup/restore, but big disk space win (boring!) • In a few moments, we will fix the boring part • Implement ID Vault • Low risk, big payback, put someone in charge – done • Roll out Sametime, upgrade, disaster recovery • Snore … Snore … Snore …

  20. Social Manipulation • The “S” word has its place in certain parts of business • Especially when it comes to getting a project completed successfully • You have to put it out there so that users are interested • And managers expect to have gain for whatever pain they might have to put up with in the short term • I was in advertising for a decade • We called this concept: • Selling the sizzle, not the steak! • A lot of it has to do with how you explain it

  21. Let’s Take a Few Examples of Good Socialization • You want a domain consolidation because it’s easier to manage one domain • You want to eliminate problems with AdminP • You want the ability to unite servers into one Notes Network • You want fewer help desk calls • Eliminate the directory catalogs and Directory Assistance • You’re going to tell them what, then? • We’re making a change to help us work better together! • It will be easier for you to invite people to meetings • You will only have to look for people in one directory • It will be easier for you to manage groups for emailing • You will work faster with less confusion

  22. How About the ID Vault? • Because you’re smart, you want to promote technical benefits • Secure way to provision Notes ID files automatically • Less support to do simple things like managing passwords • Fits well with multi-user workstation model and roaming user • Yawn … instead tell them: • No waiting for Support to visit if you just got a new laptop • Forget your Notes password? Help desk can quickly assist! • Don’t bother telling them that the help desk doesn’t need elevated security rights to do this • That would just bore them to death • ID Vault is as boring as watching paint dry • Easier setting of passwords eases pain felt by thousands of Notes users

  23. The Concept Kicker Inside of DAOS • Want to implement Domino Attachment and Object Service (DAOS)? Then you’ll probably want to tell them about: • How DAOS keeps just one copy of an attachment going to many mail files • How DAOS will help save 30% to 40% of disk space on servers • How DAOS will let you use cheaper storage for the attachments • How DAOS will change the way you do backups and restores • Resist the temptation to talk this way about DAOS • Unless users and management are suffering from insomnia • Then you are justified in this kind of an explanation • Wake me when it’s over

  24. How You Really Want to Explain Your DAOS Project • Think about selling it this way (did I say sell?) • We are going to increase mail file quotas from 500MB to 2GB! • That’s logical size, not physical size • You will no longer have to spend time trying to figure out what to delete in order to use email again • You won’t have to worry when someone sends you an attachment that you’ll go to “mail jail” • Users will love you • And will love your project • Remember – Sell the sizzle, not the steak • DAOS is boring • Raising quotas is exciting!

  25. What We’ll Cover … • Getting the right start – it’s all about the project manager • Gathering requirements that shape the project’s results • Selecting and socializing the project • Creating a project plan that gives structure to the tasks • Getting to “Yes” in day-to-day negotiations • Looking at the 5 implementation stages of every project • Making meetings count and, also, not boring • Looking like you mean business • Running around obstacles • Seven strategies for a successful technical project • Wrap-up

  26. Selecting a Tool to Manage the Project • You might be required to use a corporate-approved project management tool that integrates with other corporate projects • Use actual project management software if you can • It probably provides milestones and other high-level aspects • Management will understand how the project is going • You must be able to manage actions assigned to team members • So you can review them at meetings to make sure they get done • These are the deliverables • This is possibly the most important part of project management • Tracking who is responsible, what they are supposed to deliver, and when they are going to deliver it

  27. Spreadsheets Are a Good Solution for This • If you don’t normally work with project management software, spreadsheets are an acceptable project management tool • They will allow you to keep track of the important aspects of the project • I’ve seen some awesome project management spreadsheets • Red color coding to warn about overdue tasks • Green for things accomplished on time • Amber for tasks that might make the project slide • Include as much detail on the spreadsheet as you wish • Each day, save a new version of the spreadsheet in a Lotus Notes TeamRoom so it is accessible to everyone

  28. Keep the Original Plan as Your Baseline • Make sure you have pristine versions of the original spreadsheets or project plans • When the project has been completed, you will have a meeting to reflect on what the original plans were versus how it turned out • Some people like to call this learning experience a “post-mortem” • I think that is a bit heavy-handed, since the principle meaning for these words is an autopsy • But another even better definition is: • “A technical analysis of a finished project” • That’s a much better, and much less gross, description

  29. At Every Step There Should Be a Back-Out Plan • If you are changing the configuration of your environment, adding features, or doing upgrades, you must protect yourself from causing unplanned downtime • Unplanned downtime is the worst possible thing that can happen in a project – it is dreadful! • One way to reduce the risk of the dreadful UD is to build back-out plans • I always have back-out plans for every change I make to an environment • And I always have the back-out plans tested to make sure that they work • Someday, a strong back-out plan could save your career

  30. What We’ll Cover … • Getting the right start – it’s all about the project manager • Gathering requirements that shape the project’s results • Selecting and socializing the project • Creating a project plan that gives structure to the tasks • Getting to “Yes” in day-to-day negotiations • Looking at the 5 implementation stages of every project • Making meetings count and, also, not boring • Looking like you mean business • Running around obstacles • Seven strategies for a successful technical project • Wrap-up

  31. The Most Important Question for Negotiations • There will be a need to get people to agree with you • Whenever you are getting ready to negotiate to get what you need, you must ask yourself a very important question … • Will I ever have to negotiate with this person again? • Yes! • If you will be dealing with them in the future, you should not be overly forceful or accomplish your goals by brute strength • You have to use sound logic and be willing to change your point of view, if necessary • No! • Be ruthless, and go over their heads if they don’t cooperate • Negotiating with vendors is a good example of this approach

  32. Email/Discussion Database Not Good for Negotiations • Sometimes, stakeholders and approvers have hidden agendas • They fight your changes, or won’t approve your actions • Maybe they aren’t really as worried about your project as they are about protecting their own turf • Maybe they are secretly trying to establish new or different standards for security or the infrastructure • Maybe they just like the power of saying, “No” • Whatever their reason, “No” is not an acceptable answer

  33. Getting to “Yes” • The most effective way to get a positive answer in a corporate environment is a face-to-face discussion • Make it clear that “No” is not an acceptable answer • It can be “No” only when followed by “Unless … ,” as in … • “No, you cannot make that kind of change to servers, unless you provide a back-out plan” • “No, you cannot introduce that technology, unless you provide adequate support and training” • Stakeholders/approvers must remember the project must go on • The train has left the station • That’s why you had the Business Requirements approved

  34. What We’ll Cover … • Getting the right start – it’s all about the project manager • Gathering requirements that shape the project’s results • Selecting and socializing the project • Creating a project plan that gives structure to the tasks • Getting to “Yes” in day-to-day negotiations • Looking at the 5 implementation stages of every project • Making meetings count and, also, not boring • Looking like you mean business • Running around obstacles • Seven strategies for a successful technical project • Wrap-up

  35. 5 Stages to the Success of Your Project • These are the 5 Stages to a completed technical implementation: • Testing • Proof of concept • User acceptance testing • Pilot • Phased implementation • Almost every time I have skipped a stage, I have been totally unhappy with the result • There is a reason for doing every stage, no matter what • Because it works!

  36. Stage 1: The Test Stage • If I am running the project, testing phase is usually done on my laptop or in my office • Or the testing might be performed by one of my many minions • In this stage, we try to prove that our ideas will actually work • It’s very simple • We keep trying different things until we get one to work • There are no rules for this stage, other than to conceptualize and try to come up with solutions to accomplish the requirements

  37. Stage 2: The Proof of Concept • Proof of concept takes the successful tests and moves them out into the world, but in a very limited, controlled way • Yes, you heard me right! • I put it into production • Very important to note that this is in a very limited way • A great tool to use during the proof of concept stage isthe Friends and Family environment • Put your own team members in it • Involve players from some of the other teams, especially stakeholders who have something to gain or lose from the project

  38. Stage 3: User Acceptance Testing • You’ve tested it, You’ve built it for Friends and Family • It’s time to try it out on real people • These are people that don’t necessarily like you • They are stakeholders • The people that will represent the end users of this technology • The people that will support whatever it is your project is all about • It’s critical that whatever you are providing for the users is the actual version required by your project • There won’t be too much “wiggle room” between what you’re stating is the end product and what you are providing for user acceptance • On the other hand, this will probably be your last opportunity to make changes in your implementation

  39. Stage 4: The Pilot • Remember that we have now done: • The test stage on a laptop • The POC on a spare box in production • User acceptance testing in a formalized environment • The pilot stage is done in an environment identical to production • Just like the POC stage, the Pilot is a limited engagement • Unlike the POC, it involves substantially more people • Pilots can involve from 40 to 70 users • The pilot ensures that everything you have discovered and every configuration you have decided on actually works in production • It’s the last chance, the final galvanizing moment, that gives you courage to make the final march to implementation!

  40. What a Pilot Is Not and Pilot Participants • What a pilot is not • A pilot is not a place to test to see if it works • It is not a place to decide what features you are going to use • It is not a place to have fun and try new things • Pilot participants should be a good cross-section of users • Technically savvy people • Normal users who are just doing their jobs • Power users, like administrative assistants • Totally non-technical people

  41. Stage 5: Phased Implementation • You’ve arrived at implementation • Please keep your arms and legs in the ride at all times • Do not leave the ride until it comes to a complete stop • Even though you’ve been through a lot, it’s still extremely important for you to take it easy and start slowly • I can’t stress this enough • No matter how much testing and practice you’ve had in the previous 4 stages, this one can and will be different • There is nothing like finally running a technology in a production environment

  42. What We’ll Cover … • Getting the right start – it’s all about the project manager • Gathering requirements that shape the project’s results • Selecting and socializing the project • Creating a project plan that gives structure to the tasks • Getting to “Yes” in day-to-day negotiations • Looking at the 5 implementation stages of every project • Making meetings count and, also, not boring • Looking like you mean business • Running around obstacles • Seven strategies for a successful technical project • Wrap-up

  43. Regular Meetings Are Required • People don’t mind coming to meetings that are productive • They don’t want to waste time with meetings that go nowhere • Review all pertinent action items • It gives everyone a sense of belonging to the overall effort • It lets them know where they fit into the project as a whole • They have a better understanding of how critical they are to the overall effort and are likely to be more effective • It’s important to have regular meetings • Not everyone has to come to every meeting • Infrastructure team will only be involved in the early parts • And some teams need an FYI invitation • Not active participants, but should be kept in the loop

  44. Stick to Your Agenda • Make sure every section of the meeting has a time slot assigned to it • Stay within that time slot • Don’t let anyone run away with your meeting • If new information is brought in and you are running long, you can always table the topic until the next meeting • Tight meetings ensure proper participation • I hate meetings in general, but I love a well-run meeting • Because time is money!

  45. Track Progress • Track everything • Installation • Testing • And especially problems that need attention • Don’t be a Cleopatra • Remember her? • She was “Queen of Denial” • Face problems head-on • Your project works best when all obstacles have been overcome and all issues have been put to rest

  46. Catching Flies • My dad used to say this all the time: • “You can catch more files with sugar than you can with vinegar” • It’s true when catching management’s ear, as well • When you have one of your regular weekly meetings, take it as a casual opportunity • And if you can swing it, plan a Friday meeting every other month around lunchtime and order a couple of pizzas for the people on the team • It’s a cliché, but it works

  47. What We’ll Cover … • Getting the right start – it’s all about the project manager • Gathering requirements that shape the project’s results • Selecting and socializing the project • Creating a project plan that gives structure to the tasks • Getting to “Yes” in day-to-day negotiations • Looking at the 5 implementation stages of every project • Making meetings count and, also, not boring • Looking like you mean business • Running around obstacles • Seven strategies for a successful technical project • Wrap-up

  48. Your Appearance Is Important • Engineers, application designers, and technical project managers are focused on the facts • I’m not saying you need to wear a suit all the time • And I’m not saying it’s okay to wear shorts and flip flops • All I’m saying is, dress for the audience • It’s the professional approach and it always works • You can’t deny that it would have an effect if you gave a presentation to management wearing your favorite team’s football jersey • Just as there would be some kind of an impression if you wore a tuxedo to a meeting with network engineers • There is no question about it – how you look affects people’s opinion

  49. Dress for Success • Dress to impress when dealing with management • Meetings with the top brass should always be taken seriously • It’s an opportunity to show your professionalism • And part of being professional is knowing when you can wear jeans and when you really need to put on a suit • A suit is too much? • Lose the t-shirts, jeans, and sneakers • It demonstrates respect, and also scores serious credibility points

  50. What We’ll Cover … • Getting the right start – it’s all about the project manager • Gathering requirements that shape the project’s results • Selecting and socializing the project • Creating a project plan that gives structure to the tasks • Getting to “Yes” in day-to-day negotiations • Looking at the 5 implementation stages of every project • Making meetings count and, also, not boring • Looking like you mean business • Running around obstacles • Seven strategies for a successful technical project • Wrap-up

More Related