Calling all Project Managers – I need your Pro Tips!

Home Forums Program and Project Management Calling all Project Managers – I need your Pro Tips!

This topic contains 6 replies, has 4 voices, and was last updated by  Mark Pierson 5 years, 1 month ago.

  • Author
  • #239433

    I am currently designing a course about how to effectively setup a project and project team, so that your team is able to effectively mitigate risks and respond to challenges. Throughout the course, I would like to feature some of the cool, effective, and unique things YOU do to effectively manage your project and team.

    What are your pro tips for:
    1. Clearly defining and establishing the desired project end state (i.e. the goal/outcome and what success looks like). Do you ask yourself a series of questions? Go through a specific process? Collaborate with certain people? AND, how to ensure everyone on your project team is collaboratively working toward this desired end state throughout the project lifecycle?
    2. Clearly defining roles and responsibilities. What are your tips for assigning roles and defining boundaries around those roles so that everyone’s responsibilities are clear cut? How do you ensure everyone knows not only their own role, but the roles and responsibilities of their teammates? Do you reassessing roles and responsibilities at certain points in the project lifecycle?
    3. Building your dream team. When you’re assigned a project, how do you go about identifying the skillsets you need and the right individuals to fulfill that need? If you’re dealt a certain team, how do you maximize the talent you’re given?
    4. Defining methods for collaboration. How do you establish your leadership boundaries? Do you set ground rules for collaboration? Do you define preferred methods of communication?

  • #239437

    Darrell Hamilton

    One of my pet peeves about project management classes that I was forced to endure over the years was a desire on the part of the course to “live or die by the documented process”. Of course more projects end up dying due to the process than actually live by it. What I mean is this — every project should be considered unique. The documents and processes needed to make a project successful should be scrutinized for each project. The goal is ALWAYS to complete the task and it is never to complete the documentation. Is documentation important? Absolutely! However, the documentation is the tool and not the project.

    That being said, I believe the key document to ANY project is a project charter. The charter must describe what is the team’s goal and what success looks like. If you can’t describe success, you have absolutely no chance of getting there. Besides a good description of success, a charter could also define the project’s relative importance (“this is top priority” is only true of one project in an organization) and key stakeholders.

    Writing a good charter is more of a function of what is known or not known about the key stakeholders’ desires. If the project is starting on a vague footing (more common than anyone would be willing to admit), then it will be crucial to find a way to take the vague instructions and make it more concrete. I usually find that interviewing both the stakeholders and the eventual end users is a great place to start. For example, I was hired on for one project that would deliver a scheduling system for the pilots in an airline. The key stakeholders were the CIO, VP of operations, VP of labor relations and the pilot union board of directors. At that level, they all knew what they wanted the thing to do, but none of them had enough experience with the potential technology to know what was possible or even practical. I therefore interviewed many random pilots, the personnel in the crew scheduling office and vendors to get a sense of what everyone’s expectations were. From all of that, I was able to put together a charter (and an initial outline of the project tasks). Ultimately I learned far more than I ever needed to make the project successful, but “starting” a project that has more than it needs is far easier than trying to play catch up or get stakeholders to compromise after the start of the project.

    • #239523

      Thank you so much for your input, Darrell! Creating a charter is a great tip, and your example is fantastic. Would you mind if I reference your tip in the course?

  • #239476

    Tim Nolan

    Drop whatever you are doing and go Agile. Collin County, TX has been Agile since Sept 2011. Our AppDev uses Scrum for development and integrations, our GIS uses scrum to manage workload and our Records dept uses kanban to handle requests. As a manager, all I have to do is check the boards for progress and impedances. No status reports, no project times sheets. Agile has given me new life to a 20yr+ career.

    • This reply was modified 5 years, 1 month ago by  Tim Nolan.
    • #239525

      Tim, thank you for your response! I’m curious if there’s anything you do, or any steps you take to establish an Agile team environment?

      • #239714

        Tim Nolan

        We’ve committed to an Agile approach. We use Scrum for our AppDev & GIS teams and kanban for our Records group. Our goal is to deliver what the customer wants quickly – whether this the work is proactive or responsive.

        Our CIO suggested that we consider Agile techniques over 3 years ago. It make it much easier to implement if the boss has already green-lighted the effort. We have found that involving customers directly with the development and delivery of a project always leads to customer satisfaction.

  • #239803

    Mark Pierson

    Hi Greetings from the UK !
    In the UK we use a number of project methodologies – PRINCE 2 (A method developed by Computer IT groups in Central Government and now regarded as the standard for Project Management(very popular in the UK))
    APM Tools(A set of 50+ Knowledge areas governed by APM)-useful principles around project tools
    For IT related projects ITIL -A set of tools based on the practical real world needs required in the management of an IT project.

    Projects are really just like a cookery lesson – You need one Cook ,one menu a bunch of ingredients, some tools and an oven(senior management!!).Get the mix wrong and you end up with gooooohy food!

    Project Managers should do two key thing in managing a project- Constantly gather the information from the team and then secondly share it in an intelligent way so that all stakeholders are kept abreast of what is needed.

    Lots of new buzz words get used that confuse most people- Agile, Scrum(these are though fantastic ways to achieve rapid results!) etc
    -The key thing though is use common sense
    -spend time planning and thinking about how a project needs to work step by step.
    Looking at the comments above the other useful nugget is share concerns and dont be afraid to ask –
    most people will want to see your project succeed and will want to assist you.
    All the best and if I can assist please drop me a line – [email protected] I specialise in Change Management and Collaborative best practice for Projects in Defence & UK Government agencies/departments -trust this has been of some assistance

    • This reply was modified 5 years, 1 month ago by  Mark Pierson. Reason: spelling

You must be logged in to reply to this topic.