8
Many agile projects don't produce a software requirements specification in the sense of a document that lists a bunch of "shall" statements along with some assumptions and dependencies, like what is described in ISO/IEC/IEEE 29148 or DI-IPSC-81433A. That doesn't mean such a document can't be produced, though.
Often, agile projects will capture 'requirements'...
6
In my opinion, you need to climb higher and talk about your company's standing in its competitive market. Don't sell the IT solution; it is only one of the many enablers to a competitive business. Instead, take a look at how well your company is doing in the market place, its revenue capture as compared to total capture, its sustainability in this very ...
5
Its not Agile or Scrum if you are planning all your sprints at the beginning of the project. That's waterfall.
You may want to read about the 5 Levels of Agile Planning and use the 5 levels as an alternative to traditional waterfall planning if your business is interested in transitioning/capitalizing on the real benefits of Agile and Scrum.
Also, while ...
4
This is a problem in estimation, which is very much a PM skillset. Wish I could provide a good general answer, but the best I can do is pick at a couple of items you mention.
Since we're talking about estimating, let me mention a couple of principles:
Methodology is more important than accuracy. I've (almost) never been questioned on an estimate if I ...
4
There is no standard list of questions, defined by PMI (or any other organization). You have your own industry, your own vertical, your own org and your own group. It's very specialized...
Part 1, Chapter 5 of the PMBOK covers Project Scope Management. Chapter 5.2 is about Collect Requirements and goes through the Inputs, Tools & Techniques and Outputs ...
3
It's common, but it's not agile.
In Scrum, only the current sprint is planned in detail. That's really the whole purpose of doing a sprint -- do a small amount of work, learn from it, and then decide what to do next.
That being said, the product owner should have an idea of what will go into the following sprint, and possibly the next couple of sprints ...
2
If you have a prototype, a vision document, Personas and some PBI depending on your project I dont think you need SRS. for more complex or enterprise applications you may want to add a UML doc but I think creating a SRS doc is a lengthy process and just an additional layer of complexity that can be avoided.
2
TL;DR
Regardless of whether or not you use ROI or something else as a core metric, your real problem is that you need a way to measure the current and future value of communications. Measuring value often requires some a priori assumptions about the dimensions you will use to measure value, but once you have those dimensions you can generally assign a cost ...
2
There are some documentation instructions in different service management frameworks like Prince2, ITIL and in certifications like IEC-12207, PMMI etc. and some standards for how to draw diagrams like UML.
But if you don't want to be certified and don't care about frameworks and all that (and you don't have to unless it's mandated by law in certain domains) ...
1
You seem to need a communications management plan more than a list of questions. Build a good register of your stakeholders, specifically the senior managers who should serve as each project's sponsor, and then nail those folks down to a regular communication pattern. If they're not giving you all the information that should exist in a project's charter (the ...
1
In PMBOK terms, you'd begin with the Project Charter. PMI recommends a specific structure for it: https://www.projectmanagement.com/deliverables/289555/Project-Charter-Template
1
The cone of uncertainty has a few uses, but is most useful when used in conjunction with some other practices. So let's start with the uses in the circumstances you describe.
Cone of Uncertainty when a Commitment is Made
Obviously, you can't delay a commitment that is already made, that's a simple matter of physics (time). Most organizations I've worked ...
1
Critical success factors (CSFs) are, as the name implies, a set of conditions that must be met or a set of things that must be done to be successful. Thus, to define good CSFs, we first need to understand the goal we're trying to achieve. After that, we can define a set of things that will cause the goal to be achieved. There is a possibilty of a cause and ...
1
You could do a rough planning of future sprints, where the product owner prioritizes the backlog, and then when the next sprint comes up you do a proper sprint planning session since priorities and issues will have changed.
1
I've managed projects that used a separate wall with columns for each upcoming sprint.
As a sprint gets ready to launch, a quick analysis is made to see if the original plan still makes sense.
1
You need to conduct Feasibility study.
Operational feasibility
Economic feasibility
Technical feasibility
Human factors feasibility
Legal/Political feasibility
Usually it is conducted by customer or consultant before hiring PM and Team.
After studies there might be decision to not start a project at all.
If customer gives a green light this study shall be ...
1
Add in a "Business Value" line... you have costs and need to balance this off against benefits.
I'd also retitle:
"Cost" to read "Cost/Effort to Develop" to make sure that developer time is captured.
"Business Case Description" to read "Business Need". Where I work if someone sees the former they can get their knickers in a knot when all you want to know ...
1
Project charter is part of the initiation phase; project plan is part of project planning. The scope should be substantially the same in both places. The scope is so important to the success of the project that (literally) it bears repeating.
If the project scope is well defined in the project charter, then it is possible to simply copy it into the project ...
Only top voted, non community-wiki answers of a minimum length are eligible