Cross-client, cross-browser and roadblocks
There are all kinds of clients out there. There are the ones that don’t want to know and just disengage completely from the project. Others want fine grained control over a providers activity. Some want to get into the code and others like to tweak the front end incessantly.
Weblance is designed to help providers and clients to mesh these working styles into a productive process that deploys apps quickly. In some cases the platform will back clients off to allow providers to do their work and in other cases it will enforce client engagement to ensure that projects are fed with the client feedback necessary to deploy rapidly.
There is one thing that not even Weblance can help with however - the tinker client.
This client is googling every CS3 tutorial and constantly tinkering with the front end. Finally, when the app is supposed to go live clients are wondering why it's taking so long, why there are all kinds of cross-browser issues and why no one planned for this?
The provider explains that there is wonky HTML and tons of inline CSS and the site is riddled with incompatible browser issues. The best approach to walk through all the issues created by the client to help everyone understand the provider is not responsible.
However, the worst approach is to take the direct approach, which is what I do. The code changed…If you want me to fix, my rate is xyz.. This usually winds up in an upset client but the call next day, 100% of the time, is an apology and request to fix it.
Better than explaining what went wrong is to avoid it going wrong all together. Of course the best thing to do is just prevent the client from hacking up the front end.
Honestly this is just not possible. It is their site and they will do whatever they want. However, it is a good idea to let them know they are hacking the site before the end of the build. The question is, how to do this in a way that will let them feel the consequences without being accused of bad client management?
Using Weblance roadblocks is how! This stops the clock for a provider's deliverable commitment. If your client slaps down bad code, you can take the approach that it needs to be fixed before you can continue and enter in a roadblock. You don’t need to stop working! Just enter in a roadblock and the client knows that the deliverable date is increasing until it is fixed!
If they can’t fix it, no problem, enter the fix into your next milestone, release the roadblock and set a new deliverable date.
This makes the consequences more understandable to the client as they can feel the disruption to the project as they tinker. I am not suggesting to take a punitive approach but roadblocks protect providers from being held accountable for deliverables when clients increase scope.
Wow, roadblocks fixing age old problems. Nice.
- » W3C and WHATWG come together for HTML and DOM specifications
- » Intel launches new C++-based language as part of One API plans
- » Cloud gaming, V2X communications and Industrial IoT biggest use cases for edge development
- » WWDC 19 recap: Developers will provide the excitement
- » Android Studio to stop support for 32-bit PCs in 2020