Best Practices for Successful IT Project Management

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