If you work for an IT consulting company, then you probably know that it doesn't take much to come up with a brilliant idea for new software that could change people's lives forever. In fact, I bet you and your co-workers could name a few at any given time – it's not so difficult, really.
Your team is going out to grab lunch when someone says, “Wouldn’t it be great if you could check today’s specials for all of the lunch places around your office without having to stop by every one of them first?” Wow, if only there was an app for that.* Ideas are everywhere, and for IT consulting companies it’s a low-hanging fruit – they know the right technology, they have the right people, they might even have the time in-between their client projects. What could possibly go wrong? Four things, actually.
1) Poorly defined project roles
You and your team have worked on so many projects together that project roles shouldn’t be an issue. Everyone knows their place in the project – the business analyst gathers requirements, the project manager plans, and the programmer codes. People are excited about the prospect of developing software of their own, and they work together and come up with new features and new enhancements that will make the system truly great. Such collaborative work is extremely productive, it is fun and it’s really a piece of cake until it’s time to finalize the scope of the project. Who is the Product Owner? Who selects priorities from Feature Backlog and who is the final decision maker? With client work it’s pretty straightforward – the consulting team advise on the best technical or usability solution, but it’s really up to the client to decide how the system works or what it looks like. No professional takes it personally if a client doesn’t like their idea and decides to go against their recommendation. This might not necessarily be the case with internal software development projects, where the feeling of the system ownership is likely to be stronger than with external projects, and where the relationships between team members are somewhat personal. I guarantee you that out of the team of five, four people will have a differing opinion on what colors should be used in the system’s logo and will propose four different revisions – and that’s just one PNG file. Unless you clearly define and assign the role of the Product Owner, you and your team might find it difficult to develop a system that everyone is happy with, which often leads to team doing and redoing certain features over and over again. The Product Owner within the team will make sure the team doesn’t get distracted with minor functionality, and will also help avoid unnecessary reworks. Equally important are other key project roles. Projects are complex sets of activities performed by a group of people, leading to an a priori defined goal. These activities are connected by mutual relations and complex dependencies, and they often need to be performed at a specific time in a project life cycle. All within the scope, the budget, and the agreed timeline. IT consultants almost always work on more than one project at a time – and somehow instead of being drowned in chaos, everyone knows what to do. A Project Manager is like an air traffic controller – they make sure everyone goes in the right direction at the right time, and that the project finishes in a timely manner. And finally, Programmers – the muscle of IT projects. They estimate how much development time the system or the feature will take, and above all, they code. In the end, it is the quality of their work that makes the developed system good or bad. Just as with client projects, people simply need to feel they’re responsible for certain tasks or aspects of the project. It is this sense of personal responsibility and task ownership that ensures the work gets done.
2) Changeable budget and scope
Again, the scope and the budget of a project are usually not an issue with external client projects – the client is either willing to pay for implementing a feature or not (unless it’s a fixed-price or a waterfall project, but that’s a topic for another blog post). With internal software development projects, it’s just too easy to stray from the original plan – who wouldn’t throw in an extra 15 minutes here and there, if they were absolutely sure it would make a difference in the way the system worked or (even more often) looked? Unless you and your team specify the scope or budget up-front, you may find yourselves at 1000+ hours of development time and with software that doesn’t necessarily even work just yet (but it sure looks good!) When developing your own software, make sure the budget and/or the scope of the project are clearly defined and closely monitored throughout the development. It is usually the Project Manager who prepares the development plan, proposes milestones and deliverables, as well as sees to the launch date – just because it’s not a billable project, is not a reason to resign from good project management practices.
3) The team of second-bests
The ugly truth about internal projects is that the best managers and the highly-skilled developers rarely get delegated to work on them – they are usually snatched up for important client projects that bring money to the company. It is often the second tier consultants who end up on the internal project team: assistants, junior developers and interns, sometimes supervised by one or two senior team members. And while such internal projects might be a great learning opportunity for a “junior” team, it also means that the risk of failure is much higher than with projects developed by a more experienced team, who are reliable with their estimates and with the quality of their work. The solution is plain and simple: get the best people there are! But if your company’s hot shots are too busy working to impress some VIP clients and you simply cannot staff your team with the best of the best, then at the very least make sure you involve one senior employee or project lead who knows what they’re doing and who can serve as a mentor to the rest of the team. You might also want to review everyone’s experience and skillset, and present the team with a feasible set of goals, clear objectives, and a realistic timeline.
4) Missing deadlines
IT consulting companies earn their living by consulting their clients and by creating software for them. They have a portfolio of projects and more often than not, IT consultants are members of more than one development team within the same organization. It’s a common practice to juggle more than one project at a time, and IT consulting companies either draw from several project management methodologies or develop their own techniques that facilitate the process and allow to complete the work on time. Everything is well organized, the job gets done, and the clients are (usually) happy. Unfortunately, IT teams might be less disciplined when it comes to meeting deadlines of their internal projects. And it’s understandable, as no real money comes with internal projects (in most cases). You need to invest time and develop the software first before you can find sponsors or sell the system altogether. But until you do, there will always be more “urgent client work” that will need to be addressed ASAP and, let’s be honest, the internal project will always be the first one to be put on hold (again and again). For consulting companies, internal projects are often treated as “gap fillers” – projects and tasks that get worked on to fill the time between billable client work. However, as the client work and new sales leads come in, it is often too tempting to forsake the internal (non-billable) schedule and torpedo its chance for success.
Setting a deadline on an internal project is one thing, but working to meet the deadline and continuing to work as a consulting company at the same time, is quite another. To have a shot at success, you need to allocate the time and the resources to the internal project, and then go through with the development plan. Treating the internal project the same way as client projects will make sure it gets the attention it needs to stay on track. If you can’t commit to the development and the resource allocation plan, then you should consider not starting the project at all.
Developing your own software is definitely not easy, even for the most experienced IT consulting companies. And it’s not because of the lack of good ideas or the skill to do so – it is the project execution that poses the greatest challenge. Whether your team’s goal is simply to develop an app for internal use, or you’re hoping to reach the sky and earn your first million, keep these four potentially problematic issues in mind.
*And what happened with that impromptu ‘lunch special dilemma’ conversation that I mentioned in the beginning? Well, there’s an app for that now.