Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, Benefits Realization, Strategy
Create Project Management Processes
I recently joined a software development project. The project is mid-way. The team is operating with a Statement of Work. They currently don't have any project management processes. To get started I developed a product roadmap and a product backlog to track the completed and remaining features. Is there another way to provide more value in a short time to the project?
Sort By:
Fatema -

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.

Kiron
...
1 reply by Fatema Tuz Zohra
Oct 26, 2021 1:32 AM
Fatema Tuz Zohra
...
Hello Kiron,

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.

Fatema
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).

Thomas
...
1 reply by Fatema Tuz Zohra
Oct 26, 2021 2:50 AM
Fatema Tuz Zohra
...
Hello Thomas,

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.
Oct 25, 2021 10:53 AM
Replying to Kiron Bondale
...
Fatema -

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.

Kiron
Hello Kiron,

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.

Fatema
Oct 25, 2021 11:20 AM
Replying to Thomas Walenta
...
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).

Thomas
Hello Thomas,

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.
...
1 reply by Fatema Tuz Zohra
Oct 27, 2021 1:34 AM
Fatema Tuz Zohra
...
Thank you for detailing the three scenarios, Keith. I'm currently working on designing a transitional process. The documents that support this process are meant to complete the current project and provide future value. The company has two software implementation projects that started off as a 3 months project. But, it has stretched out to 7 months with no end in sight due to increased customization requests from the clients. My objective is to develop just enough processes to first get the project in some control.
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.
...
1 reply by Fatema Tuz Zohra
Oct 27, 2021 1:53 AM
Fatema Tuz Zohra
...
You are right that not having project management processes is not a problem. And, I agree with you on delivering value and not increasing the workload without reason. However, without a systematic approach, the development team is unable to tell how much progress has been made on each deliverable and when they were delivered. Without this information, we are unable to forecast the project's end, which is causing a hindrance in communicating a realistic timeline with the client. Currently, the team lead tracks the progress by making a mental note of what is done and what is left to do. This is one of the problems that I'm currently addressing.
Oct 26, 2021 11:25 AM
Replying to Keith Novak
...
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.
Thank you for detailing the three scenarios, Keith. I'm currently working on designing a transitional process. The documents that support this process are meant to complete the current project and provide future value. The company has two software implementation projects that started off as a 3 months project. But, it has stretched out to 7 months with no end in sight due to increased customization requests from the clients. My objective is to develop just enough processes to first get the project in some control.
Oct 26, 2021 11:49 AM
Replying to Peter Rapin
...
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.
You are right that not having project management processes is not a problem. And, I agree with you on delivering value and not increasing the workload without reason. However, without a systematic approach, the development team is unable to tell how much progress has been made on each deliverable and when they were delivered. Without this information, we are unable to forecast the project's end, which is causing a hindrance in communicating a realistic timeline with the client. Currently, the team lead tracks the progress by making a mental note of what is done and what is left to do. This is one of the problems that I'm currently addressing.

Please login or join to reply

Content ID:
ADVERTISEMENTS

"Weaseling out of things is good. It's what separates us from the other animals....except weasels."

- Homer Simpson

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events