Driving project by Not managing project

February 15, 2017 BY Frank Chin from iTGRC.Asia

  Some tips to enhance the enterprise experience and get your project closer to the real requirements from the Real Stakeholders before setting them off.  Have the ...

Did I get the real requirements from the real key stakeholders? Some tips to share Series 1.1


Some tips to enhance the enterprise experience and get your project closer to the real requirements from the Real Stakeholders before setting them off. 

  1. Have the stakeholders changed drastically? 
  2. Are they commissioned by management to commit to the project?
  3. Is their current job-scope relevant to the project scope, if otherwise how are they related to the project beside being appointed?
  4. What’s their protocol for communicating the project expectations to their business communities?
  5. How do they relate themselves to the project committee and other team members?
  6. Do they insist themselves to be involved/informed in various stage of the project? (That partially help identify themselves either as a core team member or an extended team member)
  7. Do they share concern regarding the overall impact on operation and business as usual activities? 
Different scale of project has different practices, and the culture counts a lot into the maturity of project governance. These are just a few ways to start with, to get the stakeholder/s identified by removing the fat.
How do we get the real requirements? Let’s be pragmatic. It’s not always an ideal case to capture all requirements. Being able to table 70-80% will be a reasonable benchmark. To beef it up, one or two days of workshop prior to the initiation will drive 80% of the planning effort to obtain better requirements, or have them better defined, and leave the 20% to change control during the execution. 
  1. Who raise the requirements?
  2. Are the requirements detail enough to build a use-case end to end
  3. Find out more from previous projects which were direct/indirectly related to the similar scope.
  4. Enquire the previous project owner or participant if they are available, or refer to the most relevant past project documentation as an estimated baseline.
  5. Seek better understanding about the requirements, and validate them by reaching out to people or audience outside the core team, to facilitate gap analysis that helps zooming into the real stuff. 
  6. Check if the project funding has drastically increased or decreased. Validate those factors; such as the assumptions made, preliminary constraints or risks identified if they are transparent enough to hold true under most circumstances, and remain contributing to the differences? Beside key member of the requirements, are those differences sound reasonable to other core or extended team members? 
  7. Ask the peripheral questions around the scope; such as interfaces, related interfacing process/systems/third-parties/people/roles/implicated policy be it internal, external or hidden, that they are good enough to draw the line against the “out of scope”


Practices can be gained but should also be earned through the benefit of Project Governance. Therefore unleash the potentials for more successes by “driving project without managing the project”.
Thoughts are welcome