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 ...
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, ...
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, ...
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
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
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 Startup ...
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
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
Role boundaries and swim lanes apply not only tasks and areas of decision making but also lines of accountability. And there's a difference between accountability and responsibility. In my view, the product owner is the sole owner of accountability to the end-user stakeholder. It is not shared, IMHO. The developers do own some responsibility to the ...
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
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
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
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
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
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, ...
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
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
I think if your goal is to measure customer satisfaction, then it is irrelevant what your product owner thinks. It would make no sense to ask the product owner about customer satisfaction, in case he is the one responsible to make the customer happy. Why? Because in case he does not talk about such things with his customer, he just has assumptions about it.
...
2
You certainly need to formalize this. These are controlled via service level agreements. You have desired objectives for level of severity and criteria to determine at what identified defect will be placed. Then, you simply perform against those SLAs and awarded / penalized pursuant to your performance.
In other cases, you have a cadence for delivery. ...
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 ...
1
One way to capture requirements is to put it in a document (word/pdf) with as much details as you can. Mention the stated requirements, if necessary provide wireframe diagram and also state your assumptions in the requirements. And take a written sign off from the user/customer.
Usually such requirement documents should be shared on a common portal(...
1
Clients are almost never ready immediately -- even if they are the ones who find you AND they have a tight deadline. You need to work this into your pipeline and forecasts. Also, if you follow-up too often, especially if you initiated the relationship, you run a high risk of chasing them off or appearing pushy.
I have A/B tested this with my own clients and ...
1
Did you sign a contract? For services type work, I would hope there is a written agreement on what you two negotiated. That typically seals the deal and, from there, it is a matter of you maintaining and growing that relationship, checking in with them, asking for the data and getting a date on which they commit, and following up on a set cadence.
You ...
1
it really depends on why you need the data from your customers. If you just need this data to show a demo for them, then you could use some fake data or just parse a customer's site in order to get the data you need. In this case you will be able to prepare the demo for your customers without asking them. At the next meeting, they will be so satisfied ...
1
If you do not get anything up front, then they have no 'skin in the game.' Even if your setup process is extremely automated (setup a site with one click) the reason to get money from the customer is manifold:
If the customer is unwilling to put cash up front, they have no commitment
If the customer has not given you cash, they might be trying several ...
Only top voted, non community-wiki answers of a minimum length are eligible
