16
It seems the root issue here is lack of trust between client and your company. They don't trust you will deliver the solution, whatever it is, according to a general roadmap you have. I assume that you have one. What more they don't trust you know what you do in short term. Basing on what you wrote ("we are losing control over the work to be performed") it ...
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:
...
8
Clearly Identify Your Problems
Some of our tasks require final testing from our customers to verify that they are completed according to their needs, but sometimes they don't complete the testing, or respond, for well over a week (or 3).
You actually have four problems here:
You have a "definition of done" that is dependent on people outside the Scrum ...
7
While not being a trained expert on the Agile ways, I would try to not bother the customer with uncertainty in the way of "you might not get what you asked for", but rather give him certainty that something (and be it just confirmation of the viability of a solution) can be done.
I think agile methodologies can help here. Take Scrum. Your team should commit ...
7
Regardless the methodology used for estimates, I wouldn't suggest to have the client involved in the process of estimations. Some further reasons, besides the ones you mentioned:
Clear up requirements: Estimation meetings are long enough only discussing about estimates. Discussing the cleanliness of a requirement would only add another level of complexity ...
6
Soliciting requirements is a iterative process, starting at an abstract level and diving down as you iterate. It is a data pull from the stakeholders; so it is about asking a ton of questions, several different ways, and becoming more tactical as you go along. Since it is a data pull, the techniques are not rocket science. It involves surveys, interviews, ...
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
Agile provides 3 opportunities to catch this error prior to production
The dependency should have been captured in the acceptance criteria: When story B is written, it should have been linked back to story A. And an acceptance criteria should have been written to capture that.
Unit test should break: While not all Agile teams may be writing unit tests, ...
5
Because you mention customer and vendor the situation is tricky as, depending on your specific situation, you likely have limited options in terms of confronting guys and working this through with them.
Either way I would start with understanding what are the sources of the clash. I would talk individually with the guys not to straighten things up but to ...
5
Wait, what? Why would you say no? If my customer had a request, I'd gladly sell him a solution. I'd break his request down into requirements, develop a WBS around it, estimate and price it, incorporate it into the original WBS, update my schedule and rebaseline, and get to work.
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
At the initial scoping phase of the project you need to understand what the client wants and what users want. Your project management skills will be tested in trying to balance both sets of requirements and deliver a product both are happy with.
To understand your client's requirements use the techniques that other answers have proposed including what you'...
4
I'm not sure we've answered the OP's question:
How do you prevent a situation where you have to produce work-product work first and get client feedback before getting on the right track to meet their needs?
If I understand the problem correctly, the OP is working with the client to develop the initial requirements for the project (pre-initiation). The ...
4
The first reasonable step is to learn more about the issues the customers are having. In cases like this the general advice is to collect as much data as possible. Add google analytics events to everything you can think of, take the web server log files and try to recreate the steps the users are taking. With this approach you don't have to try to recreate ...
4
Short answer
Don't formalize. Communicate more often.
Long answer
I think this situation calls for better expectation management / communication. Make explicit what you need from the customer and when, and make explicit when they can expect something back and what.
"emergency" fixes needed overnight
If you mean that the moment the customer finds bugs, ...
4
What you are discussing is a funnel for a customer feedback loop to iterate on your product.
The good news is that lots of lean startup advice exists to help and guide you solve this problem.
For an in-depth view of The Lean Startup and the measurements and metrics you should track to improve your product you can start with the Eric Reis book, Lean ...
3
As others have said - No, the client should not be in the room or involved in the estimation or planning process. Those are internal processes that should be done by those actually 'doing' the work, and who have the experience and expertise to make those estimates. Regardless of the relationship between the team and the client, the team will feel some sort ...
3
The term client suggests a buyer-seller relationship. If there is a contractual relationship with a monetary transaction, then the client has zero business in the estimation process. The client would wisely conduct its own estimation process to prepare for negotiations.
To include them is like playing poker with your cards faced up.
3
welcome to PMSE!
It isn't clear how you 'inherited' this maintenance project... The takeover from the development phase to the maintenance phase is a vital part of the process - in ITIL it's the Service Transition phase; Really worth to take a look! - some definitions are important to be highlighted:
Define a Grace Period: There's a Grace Period after the ...
3
If you can justify a support team, this will help your development effort by reducing the impact on them, as well as (hopefully) providing a better experience for your customers.
The support team should have:
Access to as much documentation as possible, including outline and detailed designs, screen layouts, etc. These artefacts must be up-to-date and ...
3
Whenever I used to conduct PM trainings and the question popped up, I use to say: "The immediate answer is:"
I'll be happy to check.
... And afterwards, record the request, prepare an analysis (impact on schedule, cost etc.), and leave the YES/NO decision to the responsible or requester (depending on whatever tolerances we have).
In other words, you ...
3
I used to use a commuting analogy.
You know it normally takes between about 40/45 minutes to get to work, so there's a basic level of uncertainty there: 40 to 45 minutes, but you don't know whether it'll be 40 minutes, 45 minutes, or somewhere in between. So you allow 45 minutes.
But on a bad day (e.g. when the traffic is unusually heavy, or a train is ...
3
Value is the high quality outcome of an organisation that the customer is willing to pay for.
Important notes:
there is a difference between output and outcome. The output is the product, the service etc. your company is providing. The outcome is the positive difference the outputs make
the value is always looked from the customer's perspective
3
I'm going to describe my experiences from the point of view of a project manager in Information Services. Some of the specifics might not exactly match your specific environment, but the principles are still the same.
This sounds like a classic case of breakdown in communication between the business resources and the technical resources. This can also be a ...
3
What you need is formal change control.
You start by capturing the requirement on a Change Request. This should detail everything the client wants to change. If the change is significant it may also require the use of a separate Requirements Specification, but that would still be referenced in the Change Request.
Once it has been submitted to the vendor, ...
3
It's like continuous quality improvement. It is about continuous improvement of the customer experience. Or the person is responsible to manage / develop / improve/ increase the customer experience, e.g. over the project lifecycle.
3
If Activity B cannot begin before Activity A is complete, it's a finish-start dependency, in PM-speak.
Alternatively, if both activities have to start at the same time (pretty rare), it's a start-start dependency.
If both activities have to end at the same time, it's a finish-finish dependency.
2
Thank you for your reference to my book "Making Sense of Agile Project Management". You're on to something very important, in my opinion. The level of uncertainty in a project is one of the most important determinants of the project management approach (either agile, traditional, or hybrid).
An example I've used in some of the talks I've given to PMI ...
2
Don't be a dick.
OK, just kidding. Well, have a good relationship and then just explain. Articulation, articulation, articulation.
Why don't you start by telling us about this complexity? What is it? Why is it complex? Will it cost money? What did you mean by 'might'? Don't you know? Had better find out.
Consider this image: http://ud.vg/blog/wp-...
2
I'll focus my answer to this question in the Project Management area.
I think the best way is being honest. In my case, if a customer ask me for doing something new, or not included at the intial scope I always estimate how it impacts in the triple constraint (scope, time cost).
If you have a good Change Management method, it'll help you justify saying no ...
Only top voted, non community-wiki answers of a minimum length are eligible
