Hot answers tagged

20

You might tackle it by highlighting increases in development costs caused by technical debt. That is a problem we are facing right now, too. Business is requesting more and more features they need when my team really wants to remove technical debt. We underlined that with less technical debt new features can be shipped way faster- and faster means cheaper. ...


8

Reflect the pain back. As things stand, your boss is not feeling the pain the team is feeling in delivering against artificial and aggressive deadlines. Your challenge is to make sure they see the consequences of their actions. Produce a sprint report that details what has or has not been tested. Make it clear that by accepting a release under these ...


7

Take a more proactive approach to dealing with technical debt In one of my previous projects, we had a major part of a site run on annual data put together by the business. Unfortunatley, the database had been architected in such a way that each year's data will go into a separate database. When it came time to launch the current year's data, it needed a ...


6

By analogy, you are asking people to replace a car that works perfectly well because you know that at some point in time the cost to maintain the existing car won't be worth the effort. You need to provide them with thoughtful estimates of when that point in time will be. In other words, the only way to convince them is to come up with a clear, justifiable ...


4

A FFP is not appropriate for your customer or you. If you pursue that you have to load it with a ton of contingency in both money and time that it would make it unfeasible for a normal customer. And it would ruin your reputation. A T&M is perfectly appropriate for this scenario. Insist on it or walk away.


3

Without detailed and fully agreed requirements, you have a load of assumptions. I suggest you document the assumptions as fully as possible, then structure a contract on a time and materials basis with the assumptions clearly stated. Then you can test the assumptions and document them as risks or issues as necessary. As an alternative to this you may prefer ...


2

To put it bluntly, from a commercial perspective people only care if you deliver the project they requested within the time and budget you promised. I have intentionally chose the word "promised" because if you don't do a proper job at communicating things, people that don't understand how the project is built will take things as a promise. And when the ...


2

One of the factors to consider is whether the client is sufficiently experienced at this kind of engagement. It only makes sense to take this kind of thing on if both parties are prepared to negotiate scope later, otherwise one or both of you is likely to come away dissatisfied. The customer should understand that "fixed" price means they pay a premium for ...


2

This is precisely why I like the Kanban approach to PM. Make a big unordered list of all the "wist list" features people have requested. Rank each feature/story in priority order. Which ones must be done now and will help the business? Once you agree on the priorities, the implementation is in your court. It shouldn't matter if the top story is going to ...


1

A lot depends on the commercial context, the business need being served and presumably the nature of the PM role as well. You have tagged this question with "Scrum" but in Scrum there is no project manager and the Product Owner is the person who is expected to be responsible for delivering business value. Irrespective of the means of delivery, most ...


1

The first metric is at least 10 times more important than any of the others. Does it fulfill the company's strategic mission? If the company doesn't know why it created a PMO, then the PMO should be shut down. Someone else will quote the precise number but if I recall correctly 90% of PMO's fail in 3 years, largely because they serve no strategic ...


1

The non-technical stakeholders only need to know how much work is needed to add the new feature. Like unit tests, refactoring should be included in the estimate for adding the new feature. It's part of the development process. If you can group features together that all benefit from the refactoring then the extra work can be spread over the group and isn'...


1

Your company is going through the maturity process and is valuing sales more than delivery. Eventually, your company will have to face its delivery metrics and likely losses and you will have the data you need to sponsor a change. Keep promoting your ideas but expect little progress for now.


1

I do not get the "cheaper" logic, but I try to find information on why it is a very bad idea. The "cheaper" logic is obvious: if you need no PM, you don't need to pay a PM and the project will be cheaper. It's a bad idea because managing a project is a job. It's not something you take on as a hobby after hours in your sales job. That's not exactly unique ...


1

A fixed price contract typically works on shifting cost risk from buyer to seller: In a T&M contract, the client has the budget risk of the project. The client is generally less experienced in doing IT projects, so the risk is high. He will estimate a budget contingency of e.g. +100%. In a Fixed-price contract, the supplier is responsible for completing ...


Only top voted, non community-wiki answers of a minimum length are eligible