February 23, 2012 at 3:23 am #154017
What do you think and why? How can we get better at it?
February 25, 2012 at 9:27 pm #154047
Travis K. AndersonParticipant
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”.
February 25, 2012 at 10:53 pm #154045
February 25, 2012 at 11:00 pm #154043
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.
February 26, 2012 at 2:07 am #154041
Short answer: Yes.
Poorly defined requirements are the normal common denominator to successful government projects. It is simple math, as garbage in=garbage out.
February 26, 2012 at 2:35 am #154039
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?
February 26, 2012 at 2:36 am #154037
What kinds of specific information do you think may be lacking which is actionable for making project decisions?
February 29, 2012 at 1:17 am #154035
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.
February 29, 2012 at 2:47 am #154033
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.
February 29, 2012 at 1:16 pm #154031
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.
February 29, 2012 at 5:16 pm #154029
Thanks Bill, excellent input! How can these be combated?
March 20, 2012 at 1:42 pm #154027
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?
March 20, 2012 at 5:40 pm #154025
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.
March 20, 2012 at 6:33 pm #154023
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?
March 20, 2012 at 8:25 pm #154021
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.
March 21, 2012 at 1:29 pm #154019
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.