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
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
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
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 ...
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
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 ...
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
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
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
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
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
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
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
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
Would not delve in graphic design issues, since my aesthetic feeling may not be shared by others. As for eliciting customer's requirements, there are a few considerations:
How do you structure and dimension your product space?
a) Structure: what attributes of the product do you consider overarching and largely constraining your design? For instance, for ...
2
For successful Agile adoption, quick and close interaction is essential amongst all the stakeholders including dev team, product owner, end-users, and client. If that is not possible then first you need to bring everyone on-board and try to convince them about the advantages of having a quick feedback loop. If that doesn't work then you adapt. Beauty of ...
2
Defining the Problems
You have only two project management problems here:
How the client's communication preferences impact the project's budget or efficiency (if they do).
Who bears the financial burden of travel costs.
There are other peripheral issues, but they are really more about how you feel about the client's communication style, or how you can ...
2
Hire or designate a Product Owner (PO)
Having part of your definition of done owned by people outside your team won't work. Customers have their own priorities and time commitments.
Based on our experience, you need a designated Product Owner (PO) as a full time member of your team to perform this role. Hire a PO or designate a person within the team, who ...
2
You cannot really force a customer to provide you with the data. And you shouldn't. You're a fresh startup. Customers put trust in you, but they don't know if you'll succeed. You can't blame them for that.
For the project at hand, you should be patient with your customer. There's a variety of possible reasons for his delay (no interest, other priorities, ...
Only top voted, non community-wiki answers of a minimum length are eligible
