Microsoft Project

  1. When you’re assigned to be project manager:
    1. Get everything you can from your client
    2. Confirm what you’ve found with your sponsor
      1. different from the client
      2. High enough in the organization to get things done but low enough so you have access to them
    3. Create the team
      1. Which functions are affected by the project (stakeholders – as many as there are)
      2. Which functions can contribute (stakeholders – as many as there are)
      3. Who can best represent these stakeholders (planning team, 4-7)
      4. Put these people on the team roster
    4. Bring team together and create project definition document.  – the HOW
      1. You want to leave this in a way that someone else could pick up your document and run the project the same way)
      2. Project objective statement
        1. clear
          1. Don’t use words your team doesn’t understand
          2. be clear on dates (not on or before 12/31)
          3. “existing resources” what does that mean? what if someone leaves? Test the sponsor about what is in your mind about what you can spend.
        2. concise – 25 words
        3. complete – scope, schedule, resources
      3. Constraint matrix – x is most constrained BECAUSE
      4. Governance process – rules and norms for the group
      5. Scope definition statement – break scope down into tangible deliverables
      6. Is-Is Not – In scope and out of scope
        1. brainstorm as much as you can
        2. post it notes – this is a good time to figure out what people are thinking
    5. Determine the planning and management approach and validate with sponsor
    6. Create the work breakdown structure dictionary (WBS) – the HOW
      1. do this informally (post-it notes). Figure out what the tasks are, break them down into a structure
      2. Major component – figure out all the tasks and break them out into groups. These groups will be the summary lines that the sponsor will track your project with
        1. Ususal groupings (decide with sponsor)
          1. deliverables
          2. phases
          3. functional groups
          4. geography
        2. Validate with sponsor. Or else they will be confused and look like a micro manager. If you’re feeling that way it’s probably because you’re giving the sponsor the wrong information, or not enough.
      3. Tasks
        1. Invite everyone who has any interest in this project
        2. Give everyone post it notes – you can organize the notes any way that makes sense as long as it makes sense to your sponsor.
        3. write down everything that needs to be done
        4. each one needs to have a verb and a noun (this is the first time you’re verbing)
        5. Don’t use the software to brain storm, use the software to document the brain storming.
        6. Before you go on, move to coding
        7. Send everyone out. you and one other person stay and manage duplicates, bad tasks.
        8. A bolded line shouldn’t have anything else in it.
      4. Coding (Nothing to do with order, about the family)
        1. Insert WBS column before
          1. they read to you the verb and noun
          2. you read back to them the the number
        2. Integers
          1. 1. BYUH
          2. 2. BYUI
            1. 2.1 HR
              1. 2.1.1. Testing
      5. Owner – every task should have an answer
        1. you go to this person for updates, creation criteria, status reports, budget. The mini project manager of that task.
        2. If you don’t have an owner for a task you are the default owner
        3. 1 owner per task
        4. DONT use the owner function in MP
      6. Completion criteria
        1. a written statement of what done looks like
        2. do this before you start working – talk to customer
        3. the owner of the task should write this
        4. others who follow these tasks can see them and request more completion points
        5. it would be good for every tasks to have it, but those that are the most complex
    7. Preliminary proejct schedule
      1. You do not create the schedule, the schedule creates itself
      2. PS = LR + TDE
      3. Preliminary Schedule = Logical relationships + Task Durration Estimate
        1. Durration drives the schedule, how many days it will take
        2. Effort drives budget. If people are charging your per hour, this will help you figure out the budget.
      4. always to long – the way you wish it were
      5. Then you cram it back into the objective statement timeline
        1. Look at the constraint matrix to decide where the wiggle room is
      6. Logical relationships
        1. with the whole team
        2. move notes around the board
        3. Everyone has ideas about this, so it’s best to get them out early
        4. Logical Relationships
          1. Predecessor > Successor – assumed by MP (finish to start)>
            1. always enter predecessors, never enter successors
              1. organize, everyone leaves except you and one person
              2. Work backwards adding predecessors
            2. Add a successor column and let that be your audit
              1. the successor helps you identify who needs it. If you can’t you either don’t need it or you haven’t identified who needs it and what they need.
            3. Duration is work days. Not effort, but work days it will take to complete.
              1. Get the right person making the estimate. The best person is the person doing the work. If you don’t know who the doer is go to the owner (not the manager). The owner is often different from the doer. Once someone is assigned go to them and validate.
            4. Start to finish – you have to finish one before you start the other
            5. start to start – you can start them at the same time
        5. a 0 durration is a milestone. Not a really important task, an announcement. Everything in the project needs to be bounded by them
      7. Schedule
        1. Change colors so you can easily see the critical path/how long things can take, etc.
        2. The project manager manages the critical path and the late start
        3. Don’t use the tracking gant because it has a weird way and it doesn’t use the late start.
      8. Budget
        1. If you are managing the budget then sit down with each person and go over their tasks and their schedule/hours
      9. Baseline
        1. Project – set baseline – set baseline
          1. the most recently approved project plan
        2. Percent complete is meaningless
      10. Task Tracking
        1. Collect status reports for one week before the meeting and the next two status periods. Give them time to forewarn you and let them know you are tracking. On time is according to the baseline.
        2. Questions to ask
          1. Did or will the task start on time? yes/no
          2. If not, when?
          3. Did or will the task finish on time?
          4. If not, when?
          5. Why? – a person whose task hasn’t started yet and in the why they will say that the predecessor says it will be late. This is an audit on other task reports
        3. Never hard code start/finish date – let Microsoft project recalculate it. You just change the duration and the predecessors.
        4. If there is a significant plan change, then you might update the baseline.
  2.  General
    1. Change new tasks to Auto Scheduled
    2. Save everything we do as a template to use later
    3. The software is not project management – you should start on context, not task. The tool does not drive the behavior, the tool should support the behavior.
    4. Don’t create false parameters for your project, know what is out there.
    5. A good process is self improving – you get better and better information at each step
    6. About 24 hours for a 12-18 month project
    7. If you change the duration, max units or the effort (fixed work) the others will change as well.
    8. Don’t ask questions you don’t need to have the answer to.
    9. Tables
      1. Entry – default
      2. Cost – budget
    10. Never ask percent complete, percent means something different to every person. It doesn’t change the project plan, it’s not useful.
    11. A good project manager builds a project plans so that someone else can take over the project. You don’t want to get stuck on the project.
    12. The purpose of the meeting is to fix the problems, not to find the problems. They should have been found before the meeting. You don’t single out the person whose task is behind.
    13. Meetings should be one-on-one so that people feel comfortable. If they are not comfortable they will be afraid to give bad news. If they need to be in groups then it needs to be a safe space.
    14. IS 562
  3. Steps
    1. Gather information
      1. don’t hide information from your team
      2. too much information is better than not enough
      3. start a repository (e.g. google docs)
      4. questions
        1. why is it a project?
        2. what did it get approved?
        3. what does the organization not know about the project
      5. the project manager is supposed to figure out what is going on. You should try to have a vulcan mind meld with your sponsor. Sometimes there ideas are half baked, and that’s ok
      6. You don’t have to like that idea, you just have to make it successful
    2. Talk to sponsor, make a team
      1. Functions (stakeholders)
        1. Which functions are most affected by the success of this project
          1. customers
          2. others in the company
          3. customers have customers – don’t bypass your customer and go to end user without permission
        2. Which functions will most contribute to the success of this project? – this is the second question.
          1. people might be answers on both questions, these are important stake holders
        3. Team
          1. rule of thumb is 4-7 team members
          2. Group the stakeholders into 4-7 common groups and find the best people to advocate for each group
          3. Always ask each team member how much time their manager has allotted for this project, never step on the toes of functional members.
          4. Every time you bring someone into the team you need to bring them immediately into the resource sheet.
          5. Essential information
            1. Name
            2. Contact Information
            3. List of stakeholders – everyone knows who is advocating for who. If you don’t delegate this you are the advocate for this stakeholder and you become the bottleneck
            4. NOT corporate title
    3. Establish framework for your project
      1. Project objective statement
        1. 25(-35) words about what you are doing (elevator pitch)
          1. past that people start processing that their own way
          2. In too many words it is easy to hide things you don’t understand
          3. It will change throughout the life of the project, when it does change you need to inform the rest of your team
        2. scope, schedule, resources
        3. not why, WHAT
        4. You need to be able to say back to your sponsor what you are doing so you can demonstrate you understand.
      2. Constraint matrix
        1. This is the mind of the sponsor so that you can counsel with them without asking every question you have.
        2. This will usually change through the life of the project
        3. You can only have one per column, one per row
        4. You usually have to tease that out of your sponsor.
        5. Resource flexibility doesn’t always mean more, it can mean different (less skilled for more skilled people, how much time you have to spend on a project)
        6. Scope flexibility doesn’t always mean take scope out. It can mean online documentation, not training, fewer cycles, less quality.
        7. Quality? – is quality a constraint? Or is it an outcome of the constraints?
        8. Responsibility/Accountability – Responsibility is a driver (managed by management), accountability –
        9. eg.
          1. Screen Shot 2014-10-14 at 10.28.24 AM
      3. Rules – how you are going to run the project
        1. If people don’t learn the rules until they break them
        2. when to meet, how often to meet, is attendance mandatory
        3. Important:
          1. How do you make decisions – consensus means that you concede. Is it a quorum? majority?
          2. Escalation – when you can’t come to an agreement how and to whom do you escalate?
          3. Manage change – No project ever goes according to plan. You can expect a major change every 90 days in a technology project. Who has to agree to change? How are you going to agree? Who has to decide? This will be strongly tied to the constraint matrix.
          4. Status – how often to collect, what information, who is responsible to collect it
      4. Deliverables – tangible output of the project
        1. How many – as many as there are
        2. Set up final deliverables, then work backwards to determine interim/expendable deliverables like prototypes
        3. A good PM will put tangibility around them so that when you get them you’ll know what they are and that they’re done
This entry was posted in Project Management. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s