17
For any project, there is a process of verification and validation of scope and acceptance of delivery. Before that occurs, the seller of services is on the hook to 'get it right.' After this occurs, there is a formal, legal, and real transfer of accountability from the seller to the buyer. This process could be a moment in time, like when you take the ...
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:
...
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?
...
12
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 ...
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
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
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 - ...
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
This is more an art form than a science, and one that is hit and miss for me. Pretty much it depends on your relationship with the client, how close you are, how formal it is but the basics are the same.
The reasons they do this:
They don't know where this fits into the bigger picture ... so they talk about the whole picture in order to orientate ...
7
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 ...
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
@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
I don't think a clause like that would be beneficial. It works both ways. You could end up answering e-mails all day long ...
Regarding communication I have used clauses for
Change management: how the change process is supposed to run and how many days before the contracting partner should react on them
warranty period (more like an SLA for support: ...
6
Client (or User) Acceptance Testing (CAT or UAT) is a critical phase of system implementation projects and should be well planned, structured and documented.
About test cases (or test scripts):
Test cases are detailed step-by-step instructions that allow to validate how the functionality works from an end-user perspective.
They should cover all user ...
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
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,...
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
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
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
As a rule of thumb: transparency and openness can go really far in terms of building trust between you and a customer. And trust is definitely kind of relation you want to build with your clients.
Considering it is an important piece of information for the customer or they directly asked about it I would just openly state that some people in a project team ...
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
