1 / 87

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

maeko
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 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!

More Related