Please login or join to subscribe to this thread
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.
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.
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.
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
- tools & features
Most of your project tasks will likely come from these changes.
Establishing the project life cycle and approach may be an important step you consider to do first.
Please login or join to reply