What’s The Biggest Challenge In Gov Projects?

Home Forums Program and Project Management What’s The Biggest Challenge In Gov Projects?

This topic contains 15 replies, has 7 voices, and was last updated by  Travis K. Anderson 5 years, 9 months ago.

  • Author
    Posts
  • #154017

    Josh Nankivel
    Participant

    Cost control?

    Schedule?

    Contract Management?

    Change Control?

    What do you think and why? How can we get better at it?

  • #154047

    Travis K. Anderson
    Participant

    Josh,

    I think the biggest challenge in Gov projects is the integration of the above four choices. Finding the right person(s) with a big picture perspective and tenacity to persevere is critical for success. Next it takes a suite of tools to produce actionable information and transparency of the current program/project status. Finally, there is a need for documented processes which should allow for scalability across the organization. I can wrap this up in two words, “Project Control”.

  • #154045

    Josh Nankivel
    Participant

    Thanks Travis!

  • #154043

    Josh Nankivel
    Participant

    I think the biggest challenge is muda — waste.

    There is a great deal of forces which create silos in agencies; funding sources, disjointed integration, lack of communication and sharing across agencies and individual projects within agencies.

    There is rarely a focus on enterprise architecture; rarely a focus on the full value stream of a product from beginning to end. Like individual companies competing with each other, projects and agencies come up with their own methods in isolation.

    In my unscientific estimation, more than half of the activity in government is waste.

  • #154041

    Jaime Gracia
    Participant

    Short answer: Yes.

    Poorly defined requirements are the normal common denominator to successful government projects. It is simple math, as garbage in=garbage out.

  • #154039

    Josh Nankivel
    Participant

    Very true. What do you think is the key driver(s) in poorly defined requirements Jaime? Why does this happen so frequently? How can we do better?

  • #154037

    Josh Nankivel
    Participant

    What kinds of specific information do you think may be lacking which is actionable for making project decisions?

  • #154035

    Scott Primeau
    Participant

    I’ve found resources, especially on IT projects, to be difficult to obtain. In a state agency, we have residency requirements and a lack of personnel funds that make attracting talent difficult. We have to rely on other factors like providing public service, a relaxed atmosphere, and max 40-he weeks to attract people.

    The results of limited resources are lower quality and many projects just not getting off the ground.

    This leads to program managers/product owners being disillusioned. That just makes it harder to get the next project launched.

  • #154033

    Josh Nankivel
    Participant

    An excellent point. I deal with this too. For me, it’s mostly just that I need more talented people. The risk of losing a few key players keeps me up at night because we’d be up a creek. And yet I either can’t convince line management to go hire the skillset I need or they are unable to find these very specialized skills. The outcome for me is operating with more risk, releases taking longer, and trying hard not to burn out key players.

  • #154031

    Bill Brantley
    Participant

    Culture – almost every government agency has a culture that resists fully realizing the benefits of project management.

    1) Silos – managers do not want to share resources nor lend out their star people to projects.

    2) Respect – project managers just don’t have the respect of agency managers for the most part.

    3) Agency problem – The classic dilemma in which the agent puts their needs before the principal’s needs. This exemplifies almost every contractor/agency relationship I have observed.

  • #154029

    Josh Nankivel
    Participant

    Thanks Bill, excellent input! How can these be combated?

  • #154027

    James Lewis
    Participant

    Jaime really nailed it there.

    Personally, I believe that lacking direction means that PM to PM processes vary. So, it’s difficult to compare apples to apples.

    Beyond that, requirements are typically established by someone else, by a contractor, or have some version of policitical flavor which is near impossible for a PM to achieve. When coupled with the fact that some projects are multiple years in maturization, the can change, meaning they are even harder to achieve.

    A huge part of the success where it relates to requirements is accountability. Who is responsible for establishing these, do they have the skills to do the job completely, and are they permitted to resist (or manage) change in order to keep a project moving toward its original requirements.

    By the way… who’s actually taking the time to ask the stakeholders if the end product is what they wanted in the first place?

  • #154025

    Josh Nankivel
    Participant

    Great point James. That’s why I love the lean/agile method my team uses…we have a demo at least every few weeks to put in front of the end user / customer and the feedback we receive is awesome. Getting that validated learning early and often is something I wouldn’t do without.

  • #154023

    James Lewis
    Participant

    That certainly is a valid and strong argument for the use of agile. But, outside the end user / customer, how do you include other stakeholders in your demos? If there are situations where your end users aren’t wholel responsible for requirements (like with political factors), how do you include stakeholders who don’t get the chance to participate in the demo?

    and, beyond that, what about situations where the requirements have been developed by a vendor, or where the vendor is doing development? do you require they perform demo’s periodically?

  • #154021

    Josh Nankivel
    Participant

    Great questions Lewis. First, my definition of ‘customer’ is very broad. On my project we have interfacing systems and even other established operational systems. Those groups are also customers, and the definition of ‘demo’ is broad and flexible too. With a user interface, it’s a meeting to show it off. With data, it’s providing that data to other teams who interface with us, notifying them of a library update so they can rebuild it in their environment, etc.

    And sometimes it’s a meeting to discuss plans as they evolve. With our data management group we were developing a new package for them recently. We meet with them regularly…at first it was high level discussions, then an excel spreadsheet we discussed with specifics, then a demo of an initial version, playground environment for them to start using it at their leisure, etc.

    As far as vendors go, I’m a contractor. There are NASA contractors I have no control over that impact our development, and I *WISH* I could require them to provide updates/demos to us on a regular basis. Unfortunately it’s all a waterfall world though, and we get updates infrequently. When we do get updates, there are lots of questions and sometimes things are just plain wrong. Or we’ve implemented based on an ICD/ISD or assumptions we had to make, and rework ensues once we find out it’s different.

    If the whole value stream were lean, we wouldn’t have this problem.

  • #154019

    Jeff S
    Participant

    Biggest challenges is the territorial nature of the people in charge of their programs. If the project involves more than one programs resources no manager wants to relinguish control of any aspect from their own program.

You must be logged in to reply to this topic.