Ways To Not Improve Development

Obvious Ideas

There are many web posts that talk about how to speed up development or otherwise complete a project on-time. The vast majority fall into two groups:

  • Simple Planning Steps
  • Platitudes

Some posts simple list the basic steps for a project, such as creating a list of needs, ensuring that you've got support from all of the stakeholders, setting a budget, and so forth. While these are important, they are not particularly original or often overlooked in a professional project. It would be very rare when I am contacted by a potential customer and they haven't already done these things. If they haven't, then we really don't want to work with them anyways, as the project is probably doomed to failure.

The other big type of post is where the company tells you that they will be smarter than the others, they will be more focused, and will use a new magic process to always stay on schedule. These really are not key differentiators between companies. While there are real differences between companies for all of those areas, there isn't any difference in their self-professed intention to deliver them. All companies will promise to do a good job and work hard.

The far more interesting questions are what does a company do that the others do not. Does one assign a non-developer project manager to talk to you about your project and its progress? Or does it allow you to talk directly to the developers? Does the company ask you for a list of technical objectives, or does it just want to hear about the business goals that you are trying to accomplish?

If you try to compare things that are not tangible, such as "developer speed", then you're really just judging the marketing ability of the companies. All companies will claim that their developers are fast, and unless you're able to work with the developers for a while, there isn't any way to tell how fast they are. You've got to find factual differences between companies and decide what one you like the best. PNWS has its approach and we believe that approach has a lot of advantages. For instance, we do not employ program managers that are not developers. We think that it is critically important to get you talking to a developer so that nothing is lost in translation. Other companies may think that a program manager to sit between you and the developers is useful. We view that as overhead that is not productive. You have to decide what approach appeals to you and your specifics.

Additional Articles