I am working on a project to enhance a software package.  To guide the programmers, I wrote a functional specification for the software.  I know that you should never tell programmers what you want, you only tell them what you want it to do.  If you have only provided information on the user function, then the acceptance testing is also easy.  It does or does not do what you documented.

Even knowing all of that, I found that I had not been pure in my functions.  I had included a how to do a function without realizing it.  It caused a bit of confusion and communication before I came to realize that the programmers were trying to do it the way I had asked when they had a much easier how that would provide the same what.

What is the lesson?  This same issue occurs when champions charter projects.  The problem statement has an assumed solution built in.  When you do this, the belt does not have the freedom to potentially arrive at a better solution.  I have found that if you only task someone with the end state goal, they are more apt to be quick and innovative.  When a champion provides too much guidance the projects seem like implementation efforts and not problem solving.

If you need someone to perform, provide them a clear understanding of the end state performance and let them go.  Now your oversight is still required but only to save them from misunderstandings and silly errors.