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
Assuming that the decisions that you want made are valid (i.e. you aren't overwhelming your customer with details that are really your responsibility to decide on), the problem seems to be that your customer, or maybe just your point of contact, is not engaged with the project. You need to address this root cause or you will spend a lot more time and effort ...
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
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
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
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, ...
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
I agree with Doug (+1) that's on customer to decide how important the project is to himself. If he doesn't dedicate enough time to the project, he may not consider it as important as you may think the project is.
It doesn't mean, however, that your team will stand still waiting for them to discuss the open points.
As you mentioned, I'd go for the first ...
6
@user1220 said it - This is where you earn your value as a PM. You have the opportunity to turn a project around. Right now this project is on a fast track to zombie status - not quite living, not quite dead, but tough to kill. You have the opportunity to change that and to transform it into something that will look fantastic on your resume.
I think @Doug ...
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
•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
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
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 ...
4
Working with your stakeholders is the most important thing you can do. Your brilliant product is garbage if your client does not buy it. Build time and budget into your plan to allow for this.
You need to remember why you are there. The solutions you develop are there for the benefit of the business, not the other way around.
4
I think you have several options:
"Reboot" the project. As you infer from your question sit down with the customer and key team members responsible for producing the product. Get them to admit the project is in trouble and create a new plan that is achievable. Besides schedule be prepared for budget and scope to change. The key point to remember is to be ...
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
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 ...
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
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
