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 to you’ll need to turn into one yourself • 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. Don’t Do the Project Without a Project Manager • You need someone to do it • And always remember: • You are more valuable as a technologist and a project manager than as either one of those alone

10. 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

11. 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

12. Business Requirements Give the Project Logic • Business Requirements tell everyone why you are doing the project in the first place • It legitimizes the entire plan • This gives you the support of all levels of management • You must have Business Requirements for the project to succeed • You need Business Requirements because: • It’s essential to get the budget dollars you need • You need management’s day-to-day support

13. Business Requirements Before Anything Else • 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

14. Keep the Business Firmly in Mind • 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

15. 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

16. Tell Them About What They’re Getting • If it’s appropriate, show them what the release can do • Deliver what they say they want • And throw in what you know they should have • Provide info for the people who will use the system • Show off the features at lunch • Provide demonstrations at lunch • Hold brown-bag seminars • Get ’em while they’re eating • Start an internal Web site and point users to it • Show practical features • For users, developers, administrators, and support teams

17. Requirements for Features and Functionality • Technical Requirements tell everyone what will be within the scope of the project • Technical Requirements will be the blueprint for your design • It sets a baseline that will be followed throughout the project • It helps prevent deadly “scope creep” • That’s when your project objectives start to expand beyond what you originally agreed to

18. Scope Creep Costs More Than Money • Scope creep can be a result of: • Poor change control • Lack of proper initial identification of what is required to bring about the project objectives • Weak project manager or executive sponsor • Scope creep is a risk in most projects • Projects that are not well defined can fall victim to scope creep • Scope creep often results in cost overrun and dissatisfaction for everyone involved • Stakeholders, users, management, and anyone else touched by the project

19. Requirements Must Be Written Down and Approved • Both sets of requirements must be written down to be effective • In this form, we refer to them as “Requirements Documents” • Business Requirements must be reviewed and approved by management • Technical Requirements must be reviewed and approved by stakeholders in the project

20. Stakeholders Are People Affected by the Project • Stakeholders are always the people that will be using the results of the project • But stakeholders can also be people affected by the project • Take a Lotus Notes upgrade project, for example • The stakeholders are certainly the users, because they will be using the new release • But the stakeholders could also be: • The workstation installation team • Help desk and support people • Business managers who want to make sure that the upgrade does not happen during a time when critical business processes occur

21. 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 in this regard • 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

22. 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

23. Make a List of Potential Projects • Consider how each project will affect the support you need to provide, and the amount of resource time that will be involved • Pick the ones that: • Have the biggest bang for the buck from the user’s perspective • Make management happy • Require the fewest resources

24. Selecting the Project • Here is a list of 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?

25. 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

26. 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 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

27. 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 about 10 years • We called this concept: • Selling the sizzle, not the steak! • A lot of it has to do with how you explain it

28. Let’s Take a Few Examples of Good Socialization • You want to do a domain consolidation because it’s easier to manage one domain than two domains • It’s too complicated • Instead, you want to have one domain to eliminate problems, with the AdminP process not going across domains • You want the ability to unite servers into the same Named Notes Networks • You want to be able to have fewer help desk calls • You want to eliminate the management of directory catalogs and Directory Assistance • You’re going to tell them what, then?

29. What You Tell Users and Management • We’re making a change to the environment 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 important updates company wide • Delegation will be easier • You will work faster with less confusion

30. How About the ID Vault? • Because you’re a technologist, you want to promote the technological benefits of the ID vault • More secure way of dealing with Notes ID files • Less support needed from Notes administrators to do simple things, like managing passwords • Provisioning of IDs is automatic • Fits well with the multi-user workstation model and roaming user • Built for use with the concept of Shared Login on a Windows workstation • Yawn …

31. What You Tell the Users • You won’t have to wait for someone from support to visit your desk if you just got a new laptop • If you forget your Lotus Notes password, the help desk can quickly assist you by setting a new one for you • Don’t bother telling them that the help desk doesn’t need elevated security rights to do this • And don’t bother telling them it makes it easier on admins • 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

32. 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

33. 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!

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. Selecting a Tool to Manage the Project • In some environments, you will 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 so that management will understand how the project is going

36. Tracking Deliverables • That’s all well and good, but you will need a tool you can understand and manipulate on a day-to-day basis • You need to manage actions assigned to team members, so that 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

37. 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 spreadsheet project management systems that are awesome • 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

38. 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

39. 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

40. 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

41. There Will Be Opportunities for Negotiations • Throughout a project, there will be a need to get people to agree with you • It could be managers or a network person • It could be a key budget approver • It could be someone who needs to approve a change that you need to make to the environment • Whenever you are getting ready to negotiate to get what you need, you must ask yourself a very important question …

42. The Most Important Question for Negotiations • Will I ever have to negotiate with this person again? • Yes! • If you will probably be dealing with them in the future, you should not be overly forceful or try to accomplish your goals by brute strength • You have to use sound logic and be willing to change your point of view, if necessary • No! • You can be ruthless, and even go over their heads if they will not cooperate • Negotiating with vendors is a good example of this approach

43. 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

44. 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

45. 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

46. 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!

47. First Stage: 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

48. Second Stage: 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

49. Introducing — The Friends and Family Environment • A great tool to use during the proof of concept stage is the Friends and Family environment • It’s a server, an environment, or a technology to unleash • 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

50. Domino Servers, New Environments, Keep Them Small • Several customers actually have FFSRV01 and FFSRV01C, a pair of small, clustered Domino servers that are the first ones to get any new technology • There are usually no more than 15 users assigned to this server • I once implemented a server that journaled Sametime chats, and implemented it for 20 people who were already Sametime users • On another occasion, I put Traveler on a back-up server, and let a collection of users on iPhones and Androids on it • I didn’t keep that server • I only used it to prove a point • The technology works!