I am working on a small project in a weak matrix environment. With no PMO to guide or no past documentations and templates. I understand the requirements and scope. I don't want to overdo things and hence not creating WBS (fair?). I am identifying activities with the help of core team and would be preparing a simple schedule. Client expectation is that I give them a milestone based schedule and a tentative date when the project will be over. What is minimum that I must keep in mind while proceeding from here? Saving Changes...
If the work is principally the development of software/data/digital content then you are right to avoid the WBS approach. Don't even try to identify activities and map them to requirements. Instead, break down the requirements into a list of deliverable features (stories) and get the team to estimate each item. If you are able to commit to deliver the software in fixed-length iterations then estimation becomes a lot simpler because your estimates only have to be good enough to decide which iteration each item should go into.
Can you suggest a method for estimation if the team is working in a functional matrix where they cannot commit continuous mandays for my project? For a 1 day task (8 hours), they can only devote 2 hours per day. So would take 4 days to complete a 1 day task. Can you guide me how should I handle the time gap in my project schedule. Saving Changes...
Manuel PerezProject Management Coordinator| Las Vegas Valley Water DistrictNorth Las Vegas, Nv, United States
Sep 01, 2022 2:34 PM
Replying to Kiron Bondale
...
Vipin -
You need to tailor your overall PM approach to fit the context of your project. Given that there seems to be no standards in place within your company, you can focus your tailoring on the bare minimum needed to address delivery and control objectives which you, your sponsor, the client and other key stakeholders would have.
There is no single set of minimum deliverables, but you'd likely want "something" to capture the defined scope (e.g. WBS, user story map, task list), a schedule at some level of detail, a budget and finances tracker at the appropriate level of detail and a RAID log of some kind to keep track of your risks, issues, actions & decisions.
Kiron
Agree. First you must know all of the project requirements, then based on those requirements you can develop the list of tasks to meet those requirements. Creating tasks without requirements leads to unnecessary scope and possibly not meeting the deliverables. Saving Changes...
Thanks Aaron. I have the tasks list and now I am further refining it with the help of development team. I found it will be complex to put all this into a WBS. I have the mandays estimate but at the same time development team has told me that they wont be able to commit continuous time for the project. So it will be complex to get their availability which is in number of hours instead of number of days. That being said a 1-day task may take 4-5 days if the responsible person is only available for 2 hours per day. And based on the dependencies of the task, this will cascade into further delays for remaining tasks. Do you think a schedule network diagram can help me? How should I including the time gaps when the developer is not available. OR when he is taking 4 days to finish a 1-day task. If i estimate 4 days then it will be wrong but my next task can only start on day 5. I need to document and estimate the start date and end date accurately based on development teams availability to come up with a milestone schedule. You are right, the key stakeholder has told me that they are not interested in the detailed task list. They only need the high level requirements explanation and then milestone schedule with end date confirmed. Your further input will be appreciated. Thank you.
One of the biggest sources of miscommunication I've experienced, when estimating tasks, has been when dealing with effort and duration. If your developers are a limited resource, and nobody is worried about the details, forget about using effort (the amount of hours needed to perform the work) and use duration (how much time will elapse before the work is completed), instead. If a developer would tell me that a task would take 4 hours (effort), I would ask how for many days until those 4 hours of work could be performed and the work completed (duration).
It's not that easy, though. When dealing with time-constrained resources, they most likely have way more work than time. They will likely pad their estimates, and then wait until the latest possible time to start the work, leaving no time for resolving any issues that may come up. It's also possible that other work will come up that bumps your work further down the list. It is imperative that you have access to a master list of work and the people prioritizing the work, then check in with the developer on a regular basis. You don't want to find out the day before the work is due that it's just getting started.
If you don't have a good prioritization and feedback system, work with others to get it set up. Make it about communication and collaboration, not control. Everyone wants to get the work done, but you'll need to break down/prevent silos to avoid surprises.
If you can manage the nuances of a duration driven schedule, you can use this to create the milestone schedule.
The one advantage I've found to this approach is that, while the developers may be maxed out on work, they aren't maxed out on one task or project. When a project needs to be expedited, you can put some work on hold while the developers focus on the priority, or add more developers to work on other priorities so your developer(s) can focus on your project. You can't always throw more bodies at one project and expect it to speed up. One of the downsides is that it might not be your project getting expedited.
Hopefully this helps. If you don't need to track/report on individual hours in your project management tool, you should have what you need for the milestone schedule. It's not perfect, but it gives you a starting point. From there, you can identify additional pain points and, hopefully, make improvements over time. Saving Changes...
Thanks Aaron. I have the tasks list and now I am further refining it with the help of development team. I found it will be complex to put all this into a WBS. I have the mandays estimate but at the same time development team has told me that they wont be able to commit continuous time for the project. So it will be complex to get their availability which is in number of hours instead of number of days. That being said a 1-day task may take 4-5 days if the responsible person is only available for 2 hours per day. And based on the dependencies of the task, this will cascade into further delays for remaining tasks. Do you think a schedule network diagram can help me? How should I including the time gaps when the developer is not available. OR when he is taking 4 days to finish a 1-day task. If i estimate 4 days then it will be wrong but my next task can only start on day 5. I need to document and estimate the start date and end date accurately based on development teams availability to come up with a milestone schedule. You are right, the key stakeholder has told me that they are not interested in the detailed task list. They only need the high level requirements explanation and then milestone schedule with end date confirmed. Your further input will be appreciated. Thank you.
Thanks Aaron. I have the tasks list and now I am further refining it with the help of development team. I found it will be complex to put all this into a WBS. I have the mandays estimate but at the same time development team has told me that they wont be able to commit continuous time for the project. So it will be complex to get their availability which is in number of hours instead of number of days. That being said a 1-day task may take 4-5 days if the responsible person is only available for 2 hours per day. And based on the dependencies of the task, this will cascade into further delays for remaining tasks. Do you think a schedule network diagram can help me? How should I including the time gaps when the developer is not available. OR when he is taking 4 days to finish a 1-day task. If i estimate 4 days then it will be wrong but my next task can only start on day 5. I need to document and estimate the start date and end date accurately based on development teams availability to come up with a milestone schedule. You are right, the key stakeholder has told me that they are not interested in the detailed task list. They only need the high level requirements explanation and then milestone schedule with end date confirmed. Your further input will be appreciated. Thank you.
In a weak matrix situation, there is a lot of uncertainty that is completely out of your control. There is only so much useful fidelity you can put into your plan because as much as you try to account for all the known-unknowns, you will inevitably encounter an unknown-unknown which means significant prior planning will no longer apply
As they say, no plan survives first contact with the enemy.
The hours to do a task tell you how long it *could* take. The duration tells you how long people think it will take. The constraints tell you when that duration needs to occur. We do our best to align those into a schedule and budget but in a weak matrix we have limited influence on priorities and staffing levels.
My solution is based on theory of constraints. Focus on the critical path. Using a precedence diagram is often useful to understanding it. Expect disruptions and use your technical and leadership skills to change the plan when needed. The critical path data is extremely useful in explaining why you need higher priority or some other type of help to execute the plan. "If we don't get the help, here is what happens to the project..."
I think agile approaches would actually be ideal in some of those weak matrix environments due to the uncertainty and the frequent need for planning changes. Unfortunately the nature of a weak matrix often means the PM is locked into a delivery model rather than trusted to select a more agile approach. Saving Changes...
Community Champion
