6

Nothing in Project Management is Free It is usually very difficult to explain to management that it will take time to repay technical debt and that the team will be even slower refactoring rather than delivering features. You already know the answer: you can't create a bigger pie by carving it into more slices. Ultimately, a team has a finite amount of ...


6

Fair is in the perception of the beholder. Win-win negotiations assume that mutual goals have been exploited to the degree possible, mutually benefiting both parties, and the relatively fair concessions were made by both parties on those goals that are not mutual. And, finally, it assumes the deal was better than your alternative, your BATNA (best ...


5

Customers prefer a FFP at times because of they believe it helps to control costs. In some ways it does; however, in many cases they end up paying more, either because of the contingency built in the price and / or the vendor submitting one change request after another. And the change requests typically have a lot of built-in margin since the CRs are not ...


5

Regarding negotiations, fairness is usually not attached to the negotiation result but to the negotiation process: Were all information accessible by all parties? Were unfair manipulation techniques involved? Having this, not all win-win situations have to be considered as fair by the negotiations parties. By the way, win-win could be considered as loose-...


4

The answer to this is in your contract. How are you contracted with the customer? If time & materials, the customer pays. If cost plus fixed fee, the customer pays but you pay too in terms of your fee margin. If fixed fee, you pay. Not only do you need to understand the payment terms, but also assumptions and exclusions agreed to in the contract. ...


4

Don't sign the contract. Say no. Look around at other industries. No other industry, EXCEPT IT, will you see this phenomena to this degree. Try it. Hire a builder and tell them they need to complete the house in three months instead of the six they told you. They'll walk away laughing. For some reason, in IT, we say yes... and then fail. Say no.


3

How can I handle these negotiations to stop accepting these activities even if they are paid? A better question would be "How do I inform the commercial staff about the risk, extra effort, scope creep, fixes, and data corrections that these activities bring to the project?" You don't negotiate to stop accepting such requests, you raise awareness on the ...


3

By my opinion you are talking about the same. What is a fairness? For me situation when both part will get maximum of outcome from negotiation is rather fair. The problem is that this is just my opinion :-) Let me explain. Let's imagine abstract negotiations involving two people (Mr. A and Mr.B). Following completion of negotiations, each party will receive ...


3

A viable strategy could be the following. First, make him truly aware of the delay he's causing: you might produce a Cumulative Flow Diagram to point out the slowdown (quite easy given that you work with Jira). Then, help him dispose the pending approvals: as Ashok said, show him how to test the user stories schedule a weekly UAT session (possibly ...


3

This is not specific to this question but rather general advice for resolving these types of inter-personal issues: try to put yourself in their shoes first. what do they gain from the current behavior? what's their benefit in resisting the change you'd like to happen? (Retaining influence, protecting their work, ...) how can they benefit in similar/same/...


3

Short answer: communicate. Do what is called a retrospective. Long answer: The only way to resolve this situation without bad blood, is to talk about it in the whole team. Tell you teammate that you have concerns regarding his work. Explain your position and let him explain his. Then try to find a solution. Don't try to force anything on anyone. It's hard ...


2

Read Belbin's Team Role Theory and French and Raven's Power Types. There are other theories, as well, so a bit of research will uncover a ton of academic conversations around your issue you are facing. The key take away is that high functioning teams gravitate its individuals to play certain, necessary roles that make it a high functioning team. It is ...


2

Here's a simplified, idealistic example of what is usually happening in this situation: Management has Team A that they think has a velocity of say 100 story points/iteration. Management thinks Team A can deliver 100 pts of business value stories each iteration. In reality Team A is is always pressured to provide more and really they can do 90 pts of ...


2

To effectively justify your estimations it is always better to have the project plan. What you're asking actually can have different answers depending on the current phase of the project. But the general solution is to operate with the plan. Depending on what is the level of awareness in your processes and IT industry in general your customer has you ...


2

Looks like a growth opportunity to me! Remember that: The customer cannot know how much effort each piece of work takes. The customer cannot know how much work you have already committed and how much bandwidth is left. So, stop looking at it as someone is trying to slam you. Make an estimate of each work item. Is there any low priority work that you ...


2

I think the question is why he's not reviewing the stories. I'd use the lean approach that Toyota developed: help the client eliminate his own bottleneck. Possible reasons: he doesn't have dedicated resources to the project he doesn't know how to review the stories (as he's external and not involved in the development efforts, he might not know all the ...


2

There's a difference between being a software vendor and being a service provider for bespoke applications development. You seem to be describing a service-provider kind of relationship. A fixed-price (FFP) contract does not mean the customer only pays a fixed price. It means the customer and supplier agree to negotiate on price and scope and that the ...


2

There are always questions that can't be answered at the start of a project. You begin with incomplete information and learn more as you go on. This is a well-known principle called the Cone of Uncertainty and it means that decisions taken at the start of a project have to be made based on information that may prove to be incomplete or inaccurate. This is ...


1

Everybody (obviously) answered yes to getting a lawyer involved. But nobody answered your first question: How does the software development company draw up a contract that protects the company's interests (doesn't cause losses)? However, besides for the legalese, the contract is going to need an addendum; specifically, a detailed Technical Spec. This will ...


1

I strongly advise you to engage an attorney who is skilled at creating this sort of contract. (And, in general, in leading clients through this sort of business negotiation. (The old-fashioned word for an attorney was, after all, "counselor.") An attorney is "an expert in the law." You are not. I stumbled-upon my personal attorney, Tom,...


1

As you mentioned yourself, the problem with software development is that there are a lot of unknowns. These introduce variability in what will be built (which people assume will be fixed). What's worse, is that in the beginning, both parties have trouble knowing what is needed and what will change after the project is started (and things will definitely ...


1

The idea behind a successful business is to supply what the customers demand. The decision to supply shouldn't be made because you find it hard, there's some rework, or other issues. Should be based on whether building and maintaining that capability would be profitable, whether you build it or buy it. So don't stop those negotiations. The bigger question ...


1

Don't. Migration is a commonly asked-for - and provided - service. If your competitors are providing it and you are not, you'll probably suffer more than you currently do doing the migration work. You have a hole in your (Team's?) skillset. My advice is to fill that hole. Either hire someone who has more experience with migrations, or else expend effort ...


1

You have no leverage and have already lost your position. Negotiation is about information: an independent estimate of cost and price (best and worst case), mutual objectives, a list of alternative choices and benefits and costs thereof, including other vendor proposals. If you had this and other necessary information, you would have a basis for approaching ...


1

Time is a matter of priority. You can do everything the client needs... you just need to negotiate it. As per the Project Management Triange, if you fix two variables, you'll vary the other. You just need to negotiate where the client wants to compromise. The client should either rely on your opinion or dive into the details... and are hard the clients ...


1

Ask whoever tested to write-up the steps for testing Because this is new development, your external client will not know the exact steps for reproducing the use-case conditions. This is most likely slowing him down. We had this same problem. Our testers then wrote-up the exact steps to follow to test each story. This is not very difficult for the testers ...


1

Preparation is key. The more you study your situation, the better your position. Never sit at the table until you know most of the answers. "Getting to Yes" written by Ury, Fisher, and Patton is a fantastic read. Also, you will want to research various cognitive biases that play a key role during negotiations, including primacy and recency biases, ...


1

My only advice is to read the book written by Kenneth W Thomas "Intrinsic Motivation at Work: What Really Drives Employee Engagement" You are the driver and the team look at you to focus their effort on something the business and the customer need. You have to trust your team and give them full ownership on how they will implement the solution and let them ...


1

Overall, I think the answer to your problem lies in more transparency, but to get that, I think it may help to re-frame your issue a bit. It sounds like there are two things happening here and I think there's value in looking at them separately. The first is that the development organization needs time for things other than coding new features. This may be ...


1

Quick Answer: During each sprint planning meeting, discuss technical debt issues and create a placeholder card in each sprint with 5-8 or so story points that will be used to address re-factoring. You can do this as well for releases. This is a way to incorporate technical debt in your teams planning and the best way to describe it to management, is ...


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