One of the challenges in project development is dealing with "scope creep" -- the often incremental changes to a project's goals, features and other specifications that can end up increasing the cost and timetable for completion of the project. Boris Mann points to Susan Mernit's excellent thoughts on the subject:
As someone who spent a lot of her career being the cutting-edge, push the mass market troublemaker, having a job being the one who says No, is an interesting experience--but it is also incredibly cool.
Working with a team of smart people who are passionate about the customer experience, the product AND the business objectives is tremendously fun--and sometimes, completely harrowing.
I've learned that No can cover a myriad of things:
* We're not going to do this right now.
* We won't do this ever, not on my watch.
* This isn't ready to be executed.
* You need to think this through more.
* What are you, nuts?
* Oh geeze, I wish we could do this..but we're not going to, not now.
While what Susan says is aimed more at internal R&D projects, Boris notes the same can be true for client work:
Many web projects, the "launch" of a site is just the beginning. *Maybe* the functionality and content are done, on simpler sites, but now it's time to start marketing and promoting the site. In most other cases, there a bunch of items that fall into a staged launch schedule (say "no" for launch and plan it for a later rollout) or in a big "future features" bucket (say "no" to it at first, and dump it in the future features bucket) which can be revisited over time. And of course, feedback from the users of any website should be taken into account when looking at these lists.
Boris says that in general he's "too nice." I can relate. After 15 years of professional work replete with enough of those hard lessons that I really should know better, I still try maybe a bit too hard to be agreeable to client requests for changes.
In comments on Boris' post, Khalid writes:
It starts with "can you add X?" and you say yes. Then "oh, and it would be nice to have Y too!", and you again say yes. Then "we cannot launch without Z! It is a must!", ad nauseum ...
Not only does this burden you, the site builder, but it takes valuable time and effort from basic features, and can delay the launch.
So, saying "No" is a way to prevent this scope creep.
There is always phase 2 ...
Indeed.
Part of this tension arises from the fact that, in the end, we want the project to conform to the client 's desires. After all, it's not our website (or DVD or video), it's the client's, and when the client wants something, the first instinct is to say "okay." And yet, and yet ... when budgets are bumped up and timetables pushed back, quite often nobody is happy. (And it can be especially problematic when you're the developer and you have other projects scheduled and limited resources to apply to them all.)
It goes back to the post to which Susan refers, by Fred Wilson:
There's always the desire to please the customers. But knowing what you are going to do and focusing on it is so critical. Saying yes might seem like no big deal. It's only a few lines of code, right? Wrong. It's never just a few lines of code. So say no as often as you can. It's counter intuitive to the entrepreneur mindset, but it's critical.
I can't say I agree with any categorical rules like this, but I can understand the root of such sentiments. I often find myself stuck between wanting to accommodate the client now vs. wanting to keep the often-complex project on track.
Susan writes:
Yep, I say No a lot more than I used to--but it makes it feel so good when I get to say yes.
I wish I could relish saying "no" as much as Susan does.
[Apologies to Kenny Rogers for the title]
]]>
One of the challenges in project development is dealing with "scope creep" -- the often incremental changes to a project's goals, features and other specifications that can end up increasing the cost and timetable for completion of the project. Boris Mann points to Susan Mernit's excellent thoughts on the subject:
As someone who spent a lot of her career being the cutting-edge, push the mass market troublemaker, having a job being the one who says No, is an interesting experience--but it is also incredibly cool.
Working with a team of smart people who are passionate about the customer experience, the product AND the business objectives is tremendously fun--and sometimes, completely harrowing.
I've learned that No can cover a myriad of things:
* We're not going to do this right now.
* We won't do this ever, not on my watch.
* This isn't ready to be executed.
* You need to think this through more.
* What are you, nuts?
* Oh geeze, I wish we could do this..but we're not going to, not now.
While what Susan says is aimed more at internal R&D projects, Boris notes the same can be true for client work:
Many web projects, the "launch" of a site is just the beginning. *Maybe* the functionality and content are done, on simpler sites, but now it's time to start marketing and promoting the site. In most other cases, there a bunch of items that fall into a staged launch schedule (say "no" for launch and plan it for a later rollout) or in a big "future features" bucket (say "no" to it at first, and dump it in the future features bucket) which can be revisited over time. And of course, feedback from the users of any website should be taken into account when looking at these lists.
Boris says that in general he's "too nice." I can relate. After 15 years of professional work replete with enough of those hard lessons that I really should know better, I still try maybe a bit too hard to be agreeable to client requests for changes.
In comments on Boris' post, Khalid writes:
It starts with "can you add X?" and you say yes. Then "oh, and it would be nice to have Y too!", and you again say yes. Then "we cannot launch without Z! It is a must!", ad nauseum ...
Not only does this burden you, the site builder, but it takes valuable time and effort from basic features, and can delay the launch.
So, saying "No" is a way to prevent this scope creep.
There is always phase 2 ...
Indeed.
Part of this tension arises from the fact that, in the end, we want the project to conform to the client 's desires. After all, it's not our website (or DVD or video), it's the client's, and when the client wants something, the first instinct is to say "okay." And yet, and yet ... when budgets are bumped up and timetables pushed back, quite often nobody is happy. (And it can be especially problematic when you're the developer and you have other projects scheduled and limited resources to apply to them all.)
It goes back to the post to which Susan refers, by Fred Wilson:
There's always the desire to please the customers. But knowing what you are going to do and focusing on it is so critical. Saying yes might seem like no big deal. It's only a few lines of code, right? Wrong. It's never just a few lines of code. So say no as often as you can. It's counter intuitive to the entrepreneur mindset, but it's critical.
I can't say I agree with any categorical rules like this, but I can understand the root of such sentiments. I often find myself stuck between wanting to accommodate the client now vs. wanting to keep the often-complex project on track.
Susan writes:
Yep, I say No a lot more than I used to--but it makes it feel so good when I get to say yes.
I wish I could relish saying "no" as much as Susan does.
[Apologies to Kenny Rogers for the title]
]]>
