13
If you are building a product for a client, your internal testing / QC work is not subject to negotiations. It is part of the work, part of the price, and there is no reduction in that area. If the client does not want to conduct UAT, that's their choice and risk to accept; however, there's secondary risk on the seller in this scenario. To mitigate the ...
12
Directly and honestly.
By the way, I think, this is a sales and negotiation question:
As far as I understood, you would like to support your customer and maybe earn some money. You would like to do both by predicting the future and you are (for whatever reason, time in your situation) not able to prove your prediction.
What is the worst case outcome?
...
10
Great project management is not about hitting your targets 100% of the time. Much of our performance is probabilistic where many of the drivers of our results are out of control and very random. Missing your targets becomes a problem if it became a surprise for you as the PM and your customer. If you were monitoring properly, such as using critical path ...
9
Wow - your cup certainly runneth over with ALL of the usual challenges that software (or any other type of) project teams face - ever increasing backlog, unreasonable customer demands (and poor support for their own deliverables) and a management/ sales team that is unable to say No to the customer. I'm not sure how senior is the delivery team's manager - ...
9
In a similar instance when we were facing delays-
We have clarified client about our organization internal structure. In our organization, resources are taken out from one project and given to another project if billing is not done. We cannot keep hold of resources indefinitely. So resource billing is to be done for the waiting time.
Resource work/...
9
Stop work immediately and get the work under a contract. Get a detailed Statement of Work that clearly identifies what is getting delivered, what activities will take place, what finished looks like, how you will invoice, how they will pay, etc. Your issue is not methods or communications or convincing them. You have no contract or are not enforcing your ...
9
Stop billing them for the activities they complain about and roll the costs into what they are willing to pay for (deliverables). You're not cheating them--you're not burdening your clients with the details. Your clients want the sausage, not the details of how it's made.
Also, if your client doesn't want to pay for the requirements gathering activity, ...
8
Here's one source: https://project-management-knowledge.com/definitions/e/external-dependency/
Simply research "external dependencies in project scheduling." Your schedule will simply be incomplete if you do not have identified in your schedule the dependencies upon which your schedule is based. Your best argument is the word, "dependency.&...
7
Project managers manage variances. You will have both favorable and unfavorable ones. It is not a matter of "asking" but rather informing. Planning values that you choose, both cost and time, are single values that live in a probabilistic range of results. For example, your project has an estimate of finishing between three to nine months. You targeted ...
6
Estimate story points and apply a velocity range
Here is the simplistic arithmetic:
You use velocity (in story points) as a measure of how much work you can accomplish in a unit of time (sprint).
You estimate the size of the project in story points.
Based on these two numbers, you can assess what commitments you can make for future delivery. For example, ...
6
The first counter to 'this requirement will be easy to deliver' should always be ask politely to list down the risks involved. Such unfounded claims are done by people who want to boast or want to challenge the team off a cliff.
The art of war in such situation is to transfer/overload ownership by asking counter specific (not open-ended) questions to the ...
5
There is nothing wrong with having several people from the project team contacting the client. As you already pointed out, some people are naturally more appropriate. If you developers are interfacing with the client's systems and there is a specific coding problem, then the dev might need to talk to a client dev contact.
Normally, the client will have ...
5
First of all, why are you adopting Agile?
Remember, Agile is a methodology, and as any methodology, is a means to obtain a result. I may be wrong, but if you're expecting Agile to solve all your problems only for being Agile, you're going to have a bad time. You may be addressing a symptom without dealing with the disease. If you try to go Agile only on ...
5
Ask them to run this simple prototype:
Copy the existing production DB (in MySQL) to a new test DB (in MS SQL)
Create a test version of the application (in Java)
Connect the test version of the application to the test DB
At that point, either the client will figure out that many pages are broken, or you will figure out that the way they have their ...
5
Product is currently in beta stage and never been public, only client
team and the team of testers have access to this.
How often is the client checking in? Do you have regular reviews? You want the feedback loop short and actionable.
The requirements are very much agile and I'm keeping hard to keep everything persistent during sprints and day to ...
5
You're not communicating well with your client
...and possibly also using your schedule incorrectly.
You're asking about milestones as though they were a pure schedule artifact. However, every example from your question and from your follow-on comments shows that "milestones" are something that your client provides. That is undesirable for at least ...
4
Firstly, if the company is already developing software for you or if money has already been paid then you are probably too late.
Penalty clauses are fairly common, but you will find that your success with introducing this one comes down to risk. In effect, what you are asking the company to do is accept all the risk of failing to deliver to requirements. ...
4
The short answer is yes.
You absolutely want to keep the client informed of limitations or other gotchas in the project. You rarely will know the full story and thus lack the perspective to know if this will be a major impact.
A longer answer needs to dig into how you got where you are. Ben, Miles and CodeGnome all touch on this in their answers. I'd ...
4
Have a Communications Plan
You appear to be missing a Communications Plan, which is an essential aspect of most projects. This plan would include details such as what your stakeholders need to know and when they need to know it.
Be Agile: Don't Prescribe Implementation Details
From a more agile perspective, a better question is whether or not the ...
4
This is commonly known as "the warranty period". In software I have seen one month or three months used very often. I have never seen 6 months offered for a bespoke development warranty.
In terms of commercial support arrangements, they are many and varied. Reading between the lines, it seems you are a small outfit, perhaps one-man band? Assuming this, you ...
4
The best way in every circumstance will boil down to understanding your client's perspective - including, but not limited to, the extent to which they value time as compared to cost and quality.
It's always tempting for the project manager to paint a rosy picture and not inform the sponsor/client of a risk. That is usually the wrong thing to do because it ...
4
I see two (or well, three, if getting a new job counts ;-) ) possible ways to deal with such situations in general:
When you receive a refusal like above: ask for clarification or more explanation, open a discussion to understand the other party's view and to come to a common agreement based on facts instead of feelings.
To avoid receiving refusals: make ...
4
To answer your question a generic sense - ALL estimates are wrong. Whether or not deviations are justifiable (or should be compensated) depends on the 'why' they were wrong.
To address it in a more specific way -
In the beginning of your question you said 'assume everything was done correctly' (i.e.: we were not at fault).
Later you said 'we could not ...
4
The Problem
[Are] there any cases...when wrong estimates can be justified?
Estimates are not guarantees. They are "educated guesses" based on experience, historical data, and a set of assumptions. If you're being asked to "justify" your estimates, you are already playing the Blame Game™ and starting from a false premise.
You can't win the Blame ...
4
Let them be emotional.
You do risk losing your client because there are many in this game that give away stuff all the time but there are a ton of downstream threats caused by that that negatively impact both the client and the ones giving free stuff away. That said, if they find your work valuable, then likely it's just a tantrum to try to get their way....
4
From a secuirty point of view, input should never be trusted. What's to say that next time it's not an emojji but some kind of textual exploit such as billion laughs attack?
At the end the day, if it is a public facing site you're going to have script kiddies pointing their tools at it that will send all kinds of data at it. If the page breaks it is your ...
4
You're describing an immature organization, seemingly political, low performing team, hostile work culture.
There is no such thing as a 100% defect free product or service of any type. And a mature organization with high performing processes and capabilities know this and have a process of continual improvement while they also have contingencies to deal ...
4
In my view, any necessary labor that was exhausted in order to build the finished product or provide a service deliverable would be chargeable to that project as a direct expense. The test would be, would an employee perform the questionable task if it were not for the product being produced? If the answer is no, then it should be a direct expense to the ...
3
TL;DR
Should I include the developers in these emails or not?
Increased direct communications, if done effectively, can improve the viability of a project. However, there are often pros and cons that must be considered. A lot depends on your project management framework, your project communications plan, and on the type of relationship you have with your ...
3
This should be documented in the communications plan. There are almost as many answers to your question as there are combinations of clients and providers, which is why each project should have a communications plan that summarizes who talks to whom about what.
In your shoes, I'd create a template communications plan for the company, and then validate key ...
Only top voted, non community-wiki answers of a minimum length are eligible