When planning the requirements definition phase of a project it is necessary for PMs and BAs to consider the diversity of stakeholders and their need for clarity, care taking and accountability.
In a recent project to implement an enterprise wide software product and related procedural and organizational change, the PM initiated a process in which a large number of business operations stakeholders from different departments would take part in the analysis and discovery of requirements for changes to the package and to plan for the procedures they would follow to make the system effective in their business areas.
The process was referred to as gap-fit analysis.
Members of each of the business units were to be introduced to the system's features that would impact their roles in a series of presentations and demos. Then the stakeholders would explore the system's features in a sand box environment. They would use their experience and knowledge of their roles to decide on change requirements.
The 7 Minute Project Manager evolved during the creation of the widely popular Official 7 Minute Workout mobile app. More general context and background can be gained from my initial article on this topic. My intent in writing this follow up article was to delve further into my experiences as the 7 Minute Project Manager by focusing the lens on the project itself; specifically, discussing what happened in the beginning. The early stages of the project can be best defined by what I would call collaborative design.
The project kicked off with a very small core team consisting of the Strategic Product Manager, the Creative Design Lead, the Project Manager (also filling the role as the product owner), and the Software Architect. We focused on general concepts and primary goals of the app. The Creative Design Lead immediately began creating rough sketches of what the user interface would look like. These rough sketches would be iterated over time eventually becoming the product wireframes - our bible for development. As more creative type resources became involved in the project, the project quickly became about creating a product that was "beautiful" - not a word typically spoken on most projects.
Design occurred at a very rapid pace. As initial feedback was gathered on one concept, that feedback was quickly turned into input for the next feature concept; keeping the consistency and the holistic flow of the app intact. To be clear, we were all about design and using design to drive requirements instead of the other way around - where requirements come first.
All projects have risks. If a potential risk of the project is not identified early, then the project will be at a high risk to complete as per schedule, within budget and to meet the expected quality. One of the current difficulties faced by a new Project Manager today is not having a sample or general risk list to refer to when identifying the project risk.
This article provides a sample and general project list that a new project manager can refer to at the beginning of their project to identify a potential risks within their project.
Project Risk Identification
Project Risk Management includes the processes of conducting risk management planning, identification, analysis, response planning, and controlling risk on a project. The objectives of project risk management are to increase the likelihood and impact of positive events, and decrease the likelihood and impact of negative events in the project.[PMBOK]
Project Risk identification is the most important process in the Risk Management Planning. Risk Identification determines which risks might affect the project and documents their characteristics. However, as recommended by [Donna Ritter], we should not spend too much time in identifying risks. After the list is made, qualitative and quantitative analysis is done to figure out which risks you spend time and/or money on.