Five common problems when mobilizing a new software project

I’ve worked in IT consulting for over 15 years. During that time I’ve had the pleasure (or pain) of leading and participating in a large number of software deliveries. I’ve found that regardless of industry or the type of software, similar problems crop up and make life harder for everyone. This is an overview of some common problems in getting a software project off the ground. 

1) I have no idea what I’m doing

Often when building software, you are attempting to do something you haven’t done before. “You“, in this case, being anyone on the project team OR any of the organization(s) involved. Maybe your organization has never had a CRM system before. Maybe the assigned Product Owner has never run an agile project before. Maybe the organization has never run an RFP process with vendors and doesn’t have much experience with collecting requirements. Maybe the assigned Project Manager has never mobilized a completely new team. Or the vendor delivering the service is expanding into a business area that they don’t know well, but are willing to cut their prices to learn more. 

Out of all the issues discussed below, this is the one that is hardest to quantify: will this be a headache? None of the examples listed above are CERTAIN to be a problem. Bright and talented people can accomplish wonderful things and most of us can still adapt and learn. And organizations with healthy cultures can still successfully do new things. However, it’s also easy to make rookie mistakes, especially if NO ONE working on the project knows any better, even to just ask “are you sure?”

When kicking off a new project, stop to ask yourself how much you really know about what you’re doing. See if you can fill at least some of your roles with the needed experience so that the rest of the team has someone to turn to for advice. Arrange training sessions, read up on lessons learned. Hire outside help if needed. And if going ahead with limited experience, try to have open and honest discussions about the situation and what you can do. Finally, do try to plan your budget and schedule to allow for these things.

2) We do have a system that works… in theory

Most companies have methodologies, delivery bibles or other documents which describe just how a project should be run. Whether it’s based on PRINCE2, CMMI, the Agile Manifesto or some “invented here” contraption, what seems to be a common thread is that the actual people who make up the project team either have no idea how to apply the model or just choose to ignore it. And whoever should be keeping tabs on the team is either overloaded or otherwise unavailable to point out that this might be a bad idea.

I’ve seen many projects where the team might claim to be using e.g. Scrum, but where even a cursory inspection of deliver practices shows otherwise. Half the work being done isn’t on the board or the tracking tools. The scope of a sprint changes every day. Generally speaking the entire "inspect and adapt” ethos is missing and the team just iterates through one sprint after another without actually identifying and fixing the issues that are causing problems.

Make sure your team not only has the necessary training and skills, but also that they are actually applying them. Make sure that someone is REALLY available to ask the hard questions and to support the team in improving their process. The sooner you take care of this, the less you’ll suffer.

3) Not just the right people, but also their time

So you’ve assigned the title of Product Owner to someone. Granted, you can’t really shift their other responsibilities elsewhere… but hey, they just need to write some stories and the technical team will take it from there, right? They should be able to handle things on top of their existing workload. Or maybe the awesome Software Architect with a list of certifications the length of his arm will never reaaaallly make an appearance outside of the sales deck and a cursory planning meeting, but surely the developers can just figure it out among themselves?

Often a lot of critical mobilization tasks don’t get the attention they need, because the needed people are swamped with other work. This is especially true for projects which are not quite “mission critical” – just something that would be very useful and profitable, but not a topic that draws the attention of the C-level executives. The investment decision is made, a game of “fill that box” is played on the organizational chart and the project kick-off is held. Six months down the line an emergency meeting is held to figure out why the project hasn’t delivered anything and why there is now a Change Request to rebuild half of the dysfunctional architecture and business rules. Rules that someone wrote in haste on a Sunday and didn’t really have time to test after a demo. A demo, during which they were mostly busy writing a status report and having two different chats on Teams related to their OTHER projects.

If business stakeholders can’t be reached to clarify requirements, the end result will not meet them. If the Product Owner doesn’t have time to document the requirements and present them to the technical team, the backlog will not reflect them. If the architect isn’t available to design an elegant solution and review the code, the end result may perform poorly or get thrown out down the line when trying to extend a pile of garbage. And if no one is actually available for User Acceptance Testing, the software may technically work – but will still be completely useless for the business case.

When staffing a project, make sure the allocations for the critical roles are realistic. Saving a penny on staffing expenses might cost a dollar in rework and wasted effort.

4) No time to do it the right way

Yeah, so we haven’t set up the build automation. It would take at least a week and we simply can’t spare the time. And we don’t have a budget for “automation”. Oh sure, we’re using two days every week on manual deployments, but we certainly can’t modify the schedule of our year-long project to get that investment back in less than a month. Let’s just keep doing what we’re doing. Forever.

I’ve often remarked that there’s never time to do things properly, but somehow there’s always time to redo them when things hit the fan. This particular problem manifests in a lot of different places, but it’s almost always a matter of not seeing the forest for the trees. Project Managers and their various counterparts might get fixated on short-term costs and make decisions which accumulate and lead to worse results over time. In some organizations, internal goal setting and performance evaluations may lead to behavior which makes the problem worse. If your Christmas bonus is tied to the project not overrunning this year’s budget, you may for some weird reason be less interested in investing more.

When confronted with “expensive now, cheaper from then on”, spend some time on calculating the Return on Investment. If the investment pays for itself during the project, do it. If it almost pays for itself during the project, maybe still do it. This is especially important for any activity that could potentially free up time from key people to be spent on something more valuable.

5) Feedback, is that a food?

So the first six sprints didn’t really deliver anything you wanted to show to the business stakeholders. “This is too technical, they won’t understand it.” After that, there were some issues with the deployments and permissions. Then the quarter was closing, so everyone was busy with their “real” jobs. Finally after months and months you finally get some feedback from the business users who are actually hands-on with the deployed solution:

This is not what we asked for.

Soliciting feedback from actual usage is extremely important, but often deferred for various reasons. Maybe the IT department thinks they know what needs to be done and the business people will get in the way of things. Maybe the technical team hasn’t really structured their demo (or their backlog items) in a way that makes sense for non-technical people. Or the stakeholders involved weren’t really paying all that much attention in the demo while reading their emails or preparing for their next meeting. In any case, often the requirements get their trial by fire far too late – the solution doesn’t do what it needs to and rework is needed, impacting budgets and schedules.

It doesn’t really matter if you can say “but this is exactly what was in story #235” – if the software doesn’t deliver what is NEEDED, there’s little comfort in knowing you fulfilled your Definition of Done and all your unit tests pass. And what was true a year ago when you started the project might no longer be relevant. And while it’s easy to say that “agile solves this”, it’s harder to keep a straight face while doing so if you need to rework most of your deliverables. Maybe multiple times. And it’s not like you have a budget or schedule to keep, right?

It’s not enough to talk about Minimum Viable Product and hope that you somehow get it right without feedback. You need to get a version of your software to the real users early and you need to keep validating your assumptions. You need to involve enough stakeholders hands-on and make sure the backlog really represents the current, best understanding of what needs to be done. Not a snapshot from years ago or the solitary vision of the Product Owner -- or even just the technical team.

Conclusion

I always tell my teams and customers that course correction on a project is a lot less painful when done early. When you’ve already allowed a project to drift off target for months or even years, it will take a lot of effort to get it back on track. The bigger the project, the bigger the pain. The topics covered here certainly won’t address all of your problems, but just knowing these things exist and pausing to think about what they might mean for you is already a step in the right direction. At least you might have a few things less to worry about.

Best of luck in your deliveries!