Let’s say it’s time for a transformational software project in your business. And you’re the C-level executive tasked with sponsoring the project.
And let’s say you’re not a software person and have never led this kind of initiative before.
What do you do?
Here’s a list of dos and don’ts intended specifically for you. These tips will help you lead a successful software project, regardless of your experience level with software.
1. Do make hard choices about scope
One of the most important things that the leader of a software project can do is to rein in scope to only what is crucial. This will necessitate some hard decisions about features that have to wait and user groups that may not get everything that they want at launch.
These scope decisions are crucial to crafting a project plan that is achievable. So get out your scalpel and pull out everything you can until you have the scope for a minimum viable product.
2. Don’t set your strategy by buzzword
Software is an area where there is always something new. And some executives we know gravitate toward the latest and the greatest ideas—just because they want to be innovative and on the cutting edge.
Your industry shouldn’t be about the new term that’s all over Twitter or LinkedIn like Blockchain or AI (artificial intelligence). It should be driven by your business strategy. If the hot new thing fits into your strategy, that’s great. But the strategy should be what drives innovation, not the other way around.
3. Don’t set arbitrary deadlines or launch dates
It’s fine to set a goal about when you want a project to go live, but that goal needs to be connected to reality. Setting an overly aggressive goal is going to lead to delays, or to an unprepared launch that remains problematic long after the software goes live.
You need to remember the the timeline is inextricably linked to the scope of work for the project. The bigger the project, the longer it will take. So when you’re planning deadlines, make sure that they accurately reflect the amount of effort needed to build what you’re trying to build.
This is one area where some software developers will be tempted to tell you what you want to hear, instead of telling you the truth. So make sure that you empower your team to tell you the truth.
4. Don’t let the project drag on and on
The other extreme of the timeline continuum is letting a project linger in development forever. Don’t do this. Find the first strategic point where you can go live, and do it. By doing this, you will:
Allow the project to start generating real value. A project that’s yet to launch can’t start to turn the ROI dial in your favor. That’s a key reason to get your software into use as soon as it’s practical to do so.
Get real feedback from real users. Users are creative. They may come up a spectacular idea that hadn’t crossed your mind for a valuable feature upgrade you want to prioritize. They will probably do crazy stuff to the software that will reveal bugs to be fixed and changes to be made. In either case, something you don’t expect will come to the surface. So instead of trying to guess and cover every possibility, get the project live and observe what users do.
At Worthwhile, we try to keep scope to what can be accomplished in about six months. We have noticed that projects that last longer than that are at more risk of scope creep and additional delays. Find the length of time that your organization and your team can stay focused, and try to keep your launch within that limit. Remember, you can always do additional phases of work to add features and functionality to the software after your initial launch.
5. Do ask questions of subject-matter experts
As a business executive, you have a lot of knowledge. You’re probably an expert in several areas of your business, with a working knowledge of other departments. Some of that knowledge may be in software.
But no matter how much you know, you need to listen to subject-matter experts when it comes to software, because the field changes so quickly and new innovations come so frequently. So make sure you’re talking to:
* User experience specialists
* User interface designers
* Software architects
* Front-end developers
* Network administrators
By getting these kinds of expertise, you will give your software project the best chance of success.
6. Don’t be scared off by constraints
When you have an idea for a software project, lots of people will give you reasons it won’t work. This is especially true in larger corporate structures where the culture is risk-adverse.
Here’s the truth—constraints aren’t bad, but they are realities. So while you shouldn’t be scared off by them, but you should be aware of what they are. Your constraints may include:
Finances—Money isn’t unlimited, no matter how successful your company is.
Security—Your company needs to protect its customers and their data, along with its intellectual property. Your software project should live within the security structure that exists in your company.
Compliance—If you’re in a regulated industry such as financial services or the medical field, you will have additional constraints created by regulations and laws. Make sure you know the landscape so that you don’t create additional liability for your company.
By knowing your constraints, you will get a clearer idea of what software you should build and how your development team should build it.
7. Don’t let IT talk you out of it too easily
While you’re investigating constraints, you’ll have conversations with IT, because that department is tasked with data security and preventing hacker attacks. IT will have very real concerns about any new software project being added to the company’s tech stack. It’s important to listen to these concerns. But these concerns should not determine the direction of the project—business strategy should.
When IT brings up reservations, take them seriously, and then talk about what to do to overcome these reservations as you launch your project.
* What processes need to be updated?
* What processes need to move more quickly than usual?
* What new hardware needs to be purchased?
* What new software tools need to be vetted?
The bottom line is this: let IT do its job. But don’t let IT refuse to change. If this new piece of software provides business value to the company, then IT needs to work with you to unlock this potential. Get them as a partner and move forward together toward launch.
8. Do keep the business goal at the forefront
This last item is the most important. Throughout the process of building and launching software, keep the business goal and the expected value on the tip of your tongue. The overarching business strategy should be clear to every person who works on your project, and it should be part of every executive-level conversation you have about the project.
This will keep everyone focused on the same goal, instead of on their personal preferences and opinions. Designers and developers will make their decisions based on the business goal. All of your internal users will test the project with the business goal in mind. Other executives will evaluate the final product by the business goal, not only in terms of their silos. This unified focus across the organization is crucial to the ultimate success of your project.
Experience helps when it comes to leading a software project, but it’s not essential. With the right mindset and the right software partners internally or externally, any executive can successfully lead software transformation.
So we conclude with one last thing for you to-do list: do it and start thinking through your software business strategy now.