Y is for Yes, Minister

In an ideal world, a project sponsor would commission a new piece of software, or a significant enhancement to something in place, and let the experts thrash out the details. The business experts would say what was needed and provide the business case for it, while the development experts (i.e. you!) would say what was feasible and estimate how much it will cost. Between them, they will hopefully arrive at a workable proposal.

Sometimes the sponsor will have to make hard choices if there is a mismatch between cost and funding, or time and deadlines, but the result should always be a project that is scoped to be realistic and achievable within the constraints.

This is not an ideal world



The reality is that your project will often be subject to political interference of some sort, whether it be big "P" or little "p".

This often shows itself as a drive to achieve a given objective with arbitrary and unrealistic constraints.

By "arbitrary", I mean set by some outside authority on the basis of factors that have nothing to do with the realities of the project. The constraints will be anything but arbitrary to the person setting them, but they are not based on any consideration of factors that you can manage within the project.

"Unrealistic" speaks for itself.

Sometimes you can negotiate more realistic expectations. Sometimes not.

This is where I would argue that good habits of thought, the theme of this series of posts, come into their own.

When it comes to negotiating changes in budget or deadline constraints, clear thinking based on experience will help build a case. Moreover, if you've already established a track record for accurate estimates and delivering on promises (both of which are made easier with sound discipline) then your assessment will carry more weight.

If the answer is still "no" then these good habits become even more important.

People often view quality as a cost. I see it as an investment: expend more effort now, and see the results in better results and lower support and maintenance over the life of the system.

But I've also found that good habits of thought and retaining a focus on appropriate quality lead to shortened development times and lower costs at the outset. Maybe it really isn't possible to deliver everything in the time available, in which case you want to be sure to recognize the most important bits and to understand the implications of leaving some aspects out.

Now is the time to home in hard on what's really important to the business - and to the person calling the shots. Now, more than ever, is the time to design for the future, to separate out elements so they can be developed quicker, or even added in later, to make your system robust so you aren't bogged down in support and rework and can move swiftly on to delivering the rest of the package.

When your back's to the wall, you really want the best tools possible at your disposal, because sometimes all you can do is grit your teeth and say, "Yes, Minister."