Project buyers guide for dummies, part 1

As someone who has been auditing projects I’ve come to realize how difficult it is for a company to buy an IT project.

There is so many things that need to be taken in account and specified, and then there is the plethora of strange terms to confuse a non tech savvy buyer leaving them at the goodwill of the supplier. And for my experience, most suppliers make lawyers look like little choir boys.

The basic an non-cloud specific things are that every company buying an it software project should pay attentation are:

  • Understanding software development process in the organization – get the project expectations to right track
  • Selecting a reputable partner – ask around from their previous customers their experiences
  • If organization doesn’t have an software specialist, hire a consultant – it will save you money!
  • Testing is a must, and you must invest to it from the very beginning
  • Select a right project model, Lean and Agile methods reduce the risk of project when requirements are not 100% clear to the details
  • Select also technical members to the steering group, “vocal” end user representative will help also to keep the project on track

Missing one or several these thing were some of the common ways to fail your projects what I’ve come to realize.

A company that is producing goods for example might be used to certain way of working, and if the project sponsors do not understand how software developing process differs from the normal manufacturing, there might be timetable and budget problems ahead. The expectations from project’s each reference group should be checked in the beginning and the project should be explained in layman terms to them. This will lessen the resistance, set expectations correct and people won’t panic on first minor problem.

It’s also a good thing to ask from other companies that had some dealings with the possible project supplier when you play a round of golf with them 🙂 Some companies do have a bad tendency of not being honest with the customer. Or not raising a flag if they realize that customer is not buying a suitable solution for the problem they’re trying to solve. A good supplier is not in for a quick cash but for long term partnership, and they will care about your problems and they will suggest a different solution for you if they realize it suits you better even if it means less money for them now. Be vary of the sales persons who try to impress you with latest hype terms, and don’t take their time to explain things a way you can understand

It is not possible for a every company to have a highly skilled architect or project manager on their payroll waiting for IT projects to come. In this case don’t make a mistake and put non-technical guy to talk alone with the supplier. Domain expertise is of course a must, and non technical domain expert must be present when the technical things are being decided. But do hire a technical consultant or advisor to your project from outside. Having one who’s on your side can greatly lessen the risk that the supplier will either bloat the timetable or select wrong technologies according to their own wishes. Technical advisor can also go through the offer with your domain experts and open up the proposed project so that they really know what they are being offered.

If it ain’t tested, it’s broken. An old saying that is unfortunately true. You must have tester(s) from the very beginning of the project with you, creating the test plan for example. It’s also a good practise that they should not all be from the same supplier. For example acceptance testing should be done by separate entity, not the supplier. Normal testing (unit testing, integration testing, regression testing…) can be done by the suppliers own testers.

Waterfall, Agile, Scrum, CMMI, Lean.. there are so many terms related to the project model and management, that it will confuse any person. Internet is full of people banging the drum for their own favourite methologies, and dissing the rest. It’s very difficult to pick a right model for a project if you have no experience running a software project. This subject is very wide and has many parameters which affect the decision, which is the most suitable model for each case. I suggest that you investigate Lean when the requirements are not that clear, Scrum if you need to get something done fast and can leave some features for later versions if timetable is critical and Waterfall if you have very complex domain and enough manpower to document it. This is a bit oversimplification, but the matter is very big and worth of it’s own post.

Steering group without any technical knowledge or end user feedback channel is just a rubberstamp which will stamp it’s own death sentence. If the steering group has no way to really understand where the project is going or can’t read the graphs it’s been presented, and can’t challenge the figures presented to it, it is useless. With enough technical knowledge from the buyers side the signs of project failing or running over budget and timetable can be read very early. Getting an good external specialist to the meetings ensures that you can read the early warning signs and act according.

These were some simple and basic things that I suggest you consider before starting a project, but in no means a complete list. Later on I’ll address the special problems what comes to buying an cloud software project

About Jani Nevalainen

Windows developer who's been working on Microsoft Platforms since 1996. Windows Phone dev MVP 2013, Windows Development Platform MVP 2014. Currently working as Technical Evangelist for Microsoft Finland Developer Experience team.
This entry was posted in Projects. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *