Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Requirements Management, Scheduling, Scope Management
Project requirements elicitiation and Activity List
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?
Sort By:
Page: 1 2 next>
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
...
2 replies by Manuel Perez and Vipin Verma
Sep 01, 2022 10:25 PM
Vipin Verma
...
I have identified about 40-50 activities and I am still adding few more. I am trying to keep the mapping between requirements and activities but little overwhelmed with data in excel as lacking a stronger PMIS tool.
Sep 07, 2022 3:26 PM
Manuel Perez
...
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.
I would suggest you first clearly define your objectives and what acceptance criteria so you know what "done" looks like.

From there you need to outline some kind of plan for the work that gets you to done. It doesn't need to be an exhaustive formal WBS, but you need something to describe the activities that will get you from current state to future state.

That information is necessary to create any sort of meaningful milestones. Those milestones could be a variety of things depending on the nature of your project, so you need to agree with your customer what is important to them in terms of tracking execution to plan. Those will often differ depending on the delivery model you use.

If it is a small simple project, you need simple meaningful milestones, so ask yourself what tells you the most about where you are in the maturity process. You don't have thousands of events to use for tracking progress, so what simple things can explain the most to people at an executive summary level.
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
I have identified about 40-50 activities and I am still adding few more. I am trying to keep the mapping between requirements and activities but little overwhelmed with data in excel as lacking a stronger PMIS tool.
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.
...
1 reply by Vipin Verma
Sep 07, 2022 12:37 PM
Vipin Verma
...
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.
The best source you can find on the matter in the context of the PMI is the "Business Analysis for Practitioners: A Practice Guide"
I agree with Kiron. You need to change the approach.
Honestly, if you want to provide a milestone based schedule and a tentative date for when the project will be over, the minimum you will need is either a WBS with estimated tasks or a backlog with estimated stories. You cannot give an accurate estimate for project duration if you don't know what the tasks are, constraints and dependencies for the tasks, and how long the tasks are expected to take. You are just guessing.

This doesn't mean you have to overwhelm others with all of the details. In my experience, most people don't want to see the full project schedule at the task level, but you need it to be able to provide them with a milestone based schedule/roadmap. It's kind of like being a magician, except that nobody wants to know your secrets. They just want magic, fast.

Another minimum is that you want to make sure you understand and document if/how the following things will be changed:

- people & organizations
- processes
- tools & features
- data

Most of your project tasks will likely come from these changes.
...
1 reply by Vipin Verma
Sep 07, 2022 12:29 PM
Vipin Verma
...
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.
Establishing the project life cycle and approach may be an important step you consider to do first.
...
1 reply by Vipin Verma
Sep 07, 2022 12:34 PM
Vipin Verma
...
Hi Veronica, you want to recommend any popular method? I have designed a context diagram that depicts solution that we have adopted. Any other tool that can help me put things in more visualized manner?
Sep 02, 2022 11:11 AM
Replying to Aaron Porter
...
Honestly, if you want to provide a milestone based schedule and a tentative date for when the project will be over, the minimum you will need is either a WBS with estimated tasks or a backlog with estimated stories. You cannot give an accurate estimate for project duration if you don't know what the tasks are, constraints and dependencies for the tasks, and how long the tasks are expected to take. You are just guessing.

This doesn't mean you have to overwhelm others with all of the details. In my experience, most people don't want to see the full project schedule at the task level, but you need it to be able to provide them with a milestone based schedule/roadmap. It's kind of like being a magician, except that nobody wants to know your secrets. They just want magic, fast.

Another minimum is that you want to make sure you understand and document if/how the following things will be changed:

- people & organizations
- processes
- tools & features
- data

Most of your project tasks will likely come from these 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.
...
3 replies by Aaron Porter, Keith Novak, and Vipin Verma
Sep 07, 2022 4:22 PM
Aaron Porter
...
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.
Sep 08, 2022 2:59 AM
Vipin Verma
...
Thanks Aaron. This helps.
Sep 08, 2022 8:20 PM
Keith Novak
...
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.
Sep 02, 2022 11:49 AM
Replying to Verónica Elizabeth Pozo Ruiz
...
Establishing the project life cycle and approach may be an important step you consider to do first.
Hi Veronica, you want to recommend any popular method? I have designed a context diagram that depicts solution that we have adopted. Any other tool that can help me put things in more visualized manner?
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

The truth is more important than the facts.

- Frank Lloyd Wright

ADVERTISEMENT

Sponsors