best practices for successful it project management n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Best Practices for Successful IT Project Management PowerPoint Presentation
Download Presentation
Best Practices for Successful IT Project Management

Loading in 2 Seconds...

play fullscreen
1 / 65

Best Practices for Successful IT Project Management - PowerPoint PPT Presentation


  • 147 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Best Practices for Successful IT Project Management' - jatin


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
what we ll cover
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
what we ll cover1
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
who will be the project manager
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
type 1 the total megalomaniac
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
type 2 just manages the project itself
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
type 3 the combo pm technologist
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?”
ask yourself an important question about who you are
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
what we ll cover2
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
setting the scope of the project
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
business requirements give the project logic
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
keep the business firmly in mind avings
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
technical requirements
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
requirements for features and functionality
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
don t forget to define finished
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
what we ll cover3
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
selecting the project
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?
make the best use of your limited resources
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
how about projects that give users big smiles
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 …
social manipulation
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
let s take a few examples of good socialization
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
how about the id vault
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
the concept kicker inside of daos
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
how you really want to explain your daos project
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!
what we ll cover4
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
selecting a tool to manage the project
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
spreadsheets are a good solution for this
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
keep the original plan as your baseline
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
at every step there should be a back out plan
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
what we ll cover5
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
the most important question for negotiations
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
email discussion database not good for negotiations
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
getting to yes
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
what we ll cover6
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
5 stages to the success of your project
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!
stage 1 the test stage
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
stage 2 the proof of concept
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
stage 3 user acceptance testing
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
stage 4 the pilot
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!
what a pilot is not and pilot participants
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
stage 5 phased implementation
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
what we ll cover7
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
regular meetings are required
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
stick to your agenda
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!
track progress
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
catching flies
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
what we ll cover8
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
your appearance is important
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
dress for success
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
what we ll cover9
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
innuendo is not your friend
Innuendo Is Not Your Friend
  • Throughout a project, be prepared with facts
    • Gather them, publish them, promote them
  • Facts like:
    • Number of users affected
    • Versions to be upgraded
    • Inventories of client machines
    • Network and server statistics
      • Bring to the table whatever the facts are that affect your project
        • Not only will you find them really useful, but they also demonstrate your command of the situation
i don t know the answer yet
I Don’t Know the Answer … Yet
  • Don’t be afraid to say, “I don’t know”
    • It’s incredibly valuable to be honest
      • And just as important to work hard to learn whatever is necessary to accomplish the project
  • If you admit when you are not 100% sure, then your team members will also be upfront
    • When they know what they are doing, it makes their tasks more likely to succeed
be firm with procrastinators
Be Firm with Procrastinators
  • Naturally, the tasks you’ve assigned people will be at the bottom of their “to do” lists
    • Some will be better than others
  • Identify the real laggards early in the project
    • Make sure they know what they are supposed to do
      • And when they are supposed to do it
what we ll cover10
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
1 keep high level people out of pilots
1. Keep High-Level People Out of Pilots
  • Sometimes, motivated managers and high-ranking people want to be “cool” and become early adopters
    • This is a huge mistake
      • They say they won’t mind service interruptions
        • This is a big fat lie!
  • Never let anyone in a pilot who has letters after their last name
    • VP, CIO, CEO, etc.
      • They are too busy to give you the feedback your project requires
      • They require too much hand holding
2 pretend you re getting paid
2. Pretend You’re Getting Paid
  • Often, technical people must run projects even though they are still fully engaged in day-to-day activities
    • Supporting users
    • Dealing with servers
    • Managing staff
  • It always helps to reflect on the fact that you are actually getting paid to do the project
    • And remember that the ability to run projects is a skill that you can add to your resume/Curriculum Vitae (CV)
      • It has real value in the marketplace
3 don t take it personally
3. Don’t Take It Personally
  • From time to time, things might go wrong
    • You might have to change your carefully crafted plans
      • There might be better opportunity for functionality
      • You might not gain all the approvals you need
      • Technology might not operate as expected
        • This is nothing to feel bad about
  • Distance yourself emotionally from your project
    • It’s only a project; it’s not the end of the world
4 business is really people
4. Business Is Really People
  • Remember that people are behind every business activity
    • At the end of the project, you’ll have to continue to work with all of the people you engaged to do the work
      • Technical people often forget this part of the puzzle
5 remember that you have power
5. Remember That You Have Power
  • Remember this important fact:
    • The person that draws the diagrams controls the project
  • When you set the design of the project, create diagrams of processes, procedures, and architecture — you are giving life to your ideas
    • Everyone else will instantly use your ideas as a starting point
      • They will argue about changes, but they will be focused on the basic processes you have created
6 manage expectations
6. Manage Expectations
  • Everyone is happy when they get what they expected
    • When it comes to projects, no one likes surprises
  • It’s better to undersell results than to oversell results
    • You can always deliver a better project with more functionality, better performance, or an easier usage profile
      • But to deliver a lesser technology is not acceptable
        • Make sure everyone knows what they’re going to get from the project
7 maintain a positive attitude
7. Maintain a Positive Attitude
  • Laugh in the face of adversity
  • Get excited about new challenges
  • And remember to keep smiling
    • Everyone will wonder what you’re up to!
what we ll cover11
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
where to find more information
Where to Find More Information
  • Easy to digest coverage of all aspects of Project Management
    • http://en.wikipedia.org/wiki/Project_management
  • Deepak Malhotra, “Six Ways to Build Trust in Negotiations,” (Harvard Business School, April 2004).
    • http://hbswk.hbs.edu/item/4033.htm
  • “Project Management: A Critical Skill for Princeton”
    • A Princeton University presentation on Project Management
    • Presented by HettyBaiz, Princeton Project Office
    • http://web.princeton.edu/sites/ppo/PMOverview.ppt
7 key points to take home
7 Key Points to Take Home
  • Establishing solid requirements is the most important part of a project because so much is based on scope
  • Pick a project that fits your requirements and user-smile quotient
  • Scope creep can ruin a project
  • Face-to-face negotiations are the most effective
  • Control your meetings carefully to get the most out of them
  • Face problems head-on, and don’t be a Cleopatra
  • Don’t be afraid to bug procrastinators
your turn
Your Turn!

How to contact me:

Andy Pedisich

andyp@technotics.com

www.andypedisich.com