June 1-3, 2022 | Virtual
Please login or join to subscribe to this thread
You mention there are no PM processes but what, if any, artifacts exist?
Before a roadmap or a backlog, a lightweight charter of some type of a project vision board would be needed to ensure that your senior stakeholders are aligned towards the purpose and key deliverables for the project.
Good luck, Fatema.
This seems a wonderful opportunity to show your contribution and support the success of the project.
You say you have a SOW, if might include elements of a charter, and I agree with Kiron that it is important to visualize the project purpose, goals etc for all stakeholders. A good tool for this is a project canvas, 1 piece of paper with the key parameters. This is static.
Second I could guess that there are a bunch of issues coming up, besides features, so visualize them too, e.g. with a Kanban board. This is dynamic, hopefully, and you could add some progress charts (milestones, burnup in features, or just the roadmap).
Third, besides the technical side of PM also consider the human side. Of the team and the customer. You could start to gather insights like a team morale index and customer satisfaction (qualified).
Thank you for your suggestion. No artifacts besides the SOW exist.
A project charter is on my master list of documentation. I started with the roadmap and backlog to see for myself and to show the team where the project is currently at.
I am going to develop the project charter and the risk register today. The intention is for these documents to serve as a template for future similar projects.
Thank you for the input.
The SOW states the high-level deliverables and the list of features that the customer aims to achieve with the project. However, it doesn't include key project control parameters such as project timeline, budget, assumptions & constraints, high-level risks, key stakeholders etc.
Yes, I am working on using visual tools like the kanban board. I've created the product roadmap to be a visual tool. Moreover, I'm incorporating the burndown chart. My conversation with the product owner regarding these visual tools was positive. Burn up chart is an excellent suggestion, I am going to test it out on sample data to determine whether it is more suitable than the burn-down chart.
I'm developing a stakeholder register and performing a stakeholder analysis. The team has been struggling to manage the requirement changes (as is common with software projects). The main issue is a dominant client representative who frequent changes to already approved requirements. I will look into the team morale index and determine how we can measure the customer satisfaction.
Thank you for your suggestion.
If you are jumping into a projectt mid-way, one thing to consider is whether your process changes will only apply to this project, you are developing a future state, or you are developing a transition state.
If you point-design your processes for your project (design for a single application), you can be efficient by including only what you need, with limited written documentation. You create tools but most of how they are used is in your own head. Using those kinds of processes in the future will require significantly more work to adapt to a new situation, or a whole new process to accommodate broader application.
If you design your processes as the future state and they're not used, you have added a lot of extra work to your project with limited value for the additional effort.
If you design a transitional process, you add some extra work to create it for future use with less adaptation. The choice you make and how much effort you should spend to address future state in addition to current project depends on your own situation, and whether you believe it is worth investing in the future value or just completing your current project.
I always find that it is always easier to implement a solution when there is a problem. You write that there are 'no project management processes' but that in itself is not a problem. Any process you implement should result in an improvement to project delivery either in terms of enhanced benefit or deduced risk. What is the harm (problem) in not having project management processes? Once you have identified the problem(s) then you can go about applying solutions to the identified problems. If you can't show a direct connection between your proposed pm processes and project benefit you will run into resistance and most likely fail. You want to help the team deliver not just add to their workload.
Please login or join to reply