14
You are actually in an enviable position in that you have a client who is engaged enough to get involved. My problem is usually one of getting that kind of attention.
Depending on the complexity of the documents and the size of the team you are probably saving more time (outside of travel) going through this FTF than dealing with it through email because:
...
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 ...
8
I agree with CodeGnome's well-founded comments about change control procedures. However the scenario you described and your question could occur regardless of how effective your change control procedures are. For now let's assume you have good controls in place but are still concerned about "how do you handle people who obviously try to add and change scope ...
8
Marketing materials like this is more of a 'you know when you see it.' The development of this type of deliverable is a back and forth process. You elicit what you can, you design and build, you test it, you go back and make changes. I would challenge you in the waste of time and money opinion. Doing it a more controlled way may save time and money, but ...
8
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
TL; DR
The bottom line is that you're using a project manager for a reason. Assuming you feel the need to explain at all, the reason you provide to the client should be substantially the same reason you provide to the rest of your organization.
Fixed-Price or Internal Process
If a project is fixed-price, or the customer is inquiring about your internal ...
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
For me, this is a question of roles. It's your role to complete the project to the clients satisfaction. And that includes method of communication. Declaring "I won't meet you that often" is putting yourself in the role of project owner, and that's not your role.
One of the first things PM's need to be clear on when beginning a project is how the client/...
6
Think of the PM as the Master Trouble-Shooter
The analysis, design and development resources are functional specialists and they are all very busy working on tasks for multiple projects. Their focus is on technical excellence. They neither have the time nor the mindset to follow-up with others to get prerequisite work done, manage contingencies, for example,...
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, ...
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
Timing is Immaterial
When you ask:
How do you handle people who...change scope at the worst possible time in the project life cycle?
you're missing the forest for the trees. It doesn't matter that the scope change comes at "the worst possible time." The issue is that your project should already have change controls in place to deal with scope issues and ...
5
•How many people (this includes programmers, designers, project managers, etc.) does this scope of a project usually involve?
•What would be the ballpark cost for developing this kind of app?
Assuming that you are the customer for this App these are questions better asked by sending out a request for proposals to several vendors who can produce this ...
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
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
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
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
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
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
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
