Web Design & Development Process: Part 8 - Decisive Reprioritization
By now, you had hoped that prioritization was this “thing” you tolerated early in the project and were happily past it, but in reality it’s as crucial now as it was in the beginning.
But first, as always, our storied history together...
So what do we hope to gain by, in a sense, going backwards?
Let go and move on
Probably not unlike a director sitting in the editor’s chair, to close a project well you have to let some things go. Is finishing this less important thing going to jeopardize this more important thing? Is this thing you were hoping to have done not proving to be generating the excitement you had hoped? Is there new information that came up that suggests some new functionality that’s simply not possible without scrapping some previous plans? We need to be able to handle all of these scenarios through rigorous self-detachment from our own hopes and dreams - at least where it makes sense to do so. And that decision comes down to reviewing priorities.
Review client priorities
In the last post, we talked a lot about how hard it is for clients to keep track of and understand everything going on in their web project, but if we’re honest - it’s hard for us too. Re-reviewing client priorities regularly, especially towards the end, is a marvelous idea because it is possible you may realize that you’re putting too much time into something they didn’t care too much about. On the other hand, you may find you are leaving off a detail that they specifically asked for and you’re running out of time to make adjustments. Admittedly it’s always better to discover that you drifted off course rather than having the client tell you at launch that you drifted off course. The former points to good self-discipline and responsibility and the latter points to recklessness and poor attention to detail. That’s a huge difference in perspective that can be caused by simply overlooking a couple of client priorities.
Review your priorities
It may sound a bit overstated, but reviewing your own priorities towards the end of the project is immensely valuable as well. There are times where I’m doing some code review of a project and realize that we truly over-architected something and have now set ourselves up for horrible technical debt, which flies in the face of our own corporate goals. Or perhaps the client is pushing for some last minute tweaks that require you to start sliding on your security goals or scalability? They may not be as important to the client as they should be, but they are important to you in building quality software and you need to know when to push back. Ultimately your priorities should be for the good of the client, even if they don’t see it that way. You know that there are some important elements to the build that will cause you some serious headaches later and can’t be compromised for that last minute feature. So remember what you care about and remind them when necessary.
One more to go, and it’s a doozy. We need to finish this thing right and the final step is where we (and the client) find out just how much we care about all of this.