Planning a Low-Code Development Project

Maybe you've found that the software you've been using for years isn't working the way it used to. You might be stretching spreadsheets to their limits, or frustrated by trying to get two different apps to "play nice" together to get the results you want.

Whatever the reason, you're ready to take the plunge into low-code development and want to start planning your first project.

Managing any kind of development process comes with some hurdles, and low-code development is no exception. In addition to the normal project management pitfalls, there are new issues—where should you start with your plans? What tasks will change in scope or complexity? How can you figure out a reasonable timeline, and make sure you stick to it?  We'll cover it all.

Before you start: Choosing a project management methodology

Before you create your project plan, you need to choose a methodology for approaching the project as a whole.

Lean development: Great for low-code

"Lean" is a management philosophy that extends across both product and project management. It started with Toyota in the 1970s and has enjoyed something of a renaissance over the last 10-15 years, with Lean Startup methodology bringing it into the mainstream.

The general idea is to eliminate waste wherever possible, use resources as efficiently as possible, and iterate incrementally. The focus on quick iteration and getting a functioning product to the user is a perfect match for low-code development.

For example, instead of starting with creating the most complex version of your app, you would create a version that solves 1-2 of the most pressing issues. In Lean Startup terms, this is called the MVP or Minimum Viable Product. You'd release that app to users, then gather data on how they're using it before adding more features.

This technique is based off of the scientific method and allows you to test your assumptions about how users will interact with the app. If you build all of the features based on an assumption about your users, then realize that assumption was wrong, you have to start over from scratch. However, if you've only built one or two features, you've spent much less time and can iterate more quickly, honing in on what works.

When to use other methods?

Lean development has been adopted by much of the tech industry, but that doesn't mean you have to use it or that it's always the best way. This is especially true if you're developing an app for internal use. If your app is meant to automate and improve on an existing workflow, it's unlikely that your assumptions about user behavior are wrong.

Additionally, if your organization is going to mandate app adoption, you don't have to worry about attracting and retaining users. In that case, you may still want to develop in iterative cycles. However, your focus would be on getting buy-in from stakeholders and aligning the app with the goals of the organization, rather than testing every feature with end users before starting on the next feature.

Another thing to consider is who will be building the app. If your team is in a position where you have to borrow technical talent or resources from other teams to create or improve the app, then an iterative process could make progress frustratingly slow. But, if you and your team will be working on this and learning the low-code tool yourselves, then a lean, iterative process might be just the ticket.

Planning your project

Once you've chosen how you want to manage your project, it's time to figure out how to put that approach into action.

Setting the scope for your project

The first thing you'll need to do is decide on the scope for this project. When it comes to using low-code tools, the way you approach a project's scope (and the overall planning process) often looks a little different than a standard development project.

For example, let's say you or someone on your team has some amount of development experience and/or has used a low-code platform before. Because of that, you know you'll be able to update and refine the app later. In this case, you might start with a simple 1.0 version of the app, just to test the concept and start getting feedback from the end-users. Since you know how to add features over time, and can do so on your own, you can create a minimum viable product very quickly and iterate as you go.

Now, picture a completely different scenario—one where you're borrowing another team and/or their resources to create the app. In this scenario, you may want to shoot for the moon, as it were, and ask for your ideal dream version of the app. If a technically-skilled team is working on it, their development timeline will likely be much shorter than it would be if they were coding from scratch. This results in a more complete app, which should go longer before it needs an update. That gives you and your team time to familiarize yourself with the low-code tool and create a new wishlist of features to add or improve.

Choosing milestones 

When you're scoping your project, come up with milestones so you can gauge whether or not the project as a whole is on track. When it comes to planning projects, milestones will often (but not always) correspond with the project being 25%, 50%, or 75% done (or happen along other intervals - every 20%, for example). 

You can scale milestones up or down to match the size and timeline of the project. Milestones for a customer-facing, feature-rich app will be different than milestones for an app built to streamline and automate internal processes. Whatever your milestones are, they should be as concrete and specific as possible, and move you towards completing your overall project goals.

Let's say you're building an app for internal use. In this case, your number one priority is automatically tracking and confirming deliveries. One of your milestones might be "Test integration with USPS website and tracking numbers."

On the other hand, when building a customer-facing app, your priorities are different. You might put a lot of emphasis on user research and usability testing, and have milestones associated with those phases. Example milestones, in this case, could be "create user persona documents after interviewing X potential users," or "complete usability testing with a beta version of the app."

Setting a timeline

Timelines and milestones go hand-in-hand, so there are a few areas of overlap when creating them. To create a reasonable timeline, you can break each milestone down into a concrete list of tasks, then create a time estimate for each of those tasks. If you can, base your time estimates on timesheets from previous projects or iterations of the app, so they'll be as accurate as possible.

Once you've created a time estimate that's data-based and feels reasonable, add some padding. A good rule of thumb is to multiply your total estimate by 1.25-1.5x. That might seem like too much padding, but it's always better to have more time than not enough. If you want to make the most of any "extra" time, you can create a list of backburner features that you'd like to include in a future iteration of the app, with hour estimates for each of them. If you find yourself ahead of schedule, you can choose something from that list to work on, once the original list of deliverables is complete.

We recommend that you schedule plenty of time for you and your team to get familiar with the low-code tool and its documentation. If you're creating the app yourself, you should build extra padding into the research and planning phase for your first low-code project, to account for you and your team learning the ropes.

For example, Creator uses a scripting language called Deluge. For your first project, you'll want to factor in time for reading the Deluge documentation, watching how-to videos, attending webinars, or even going through the training course that matches your background. Of course, that learning time won't be the same for everyone. Deluge has a lot of similarities with JavaScript, for example, so if you're already familiar with that, then you'll learn the ropes faster.

Keeping your project on track

Once you start putting your plan into action, your focus will shift to making sure the project proceeds according to plan.

Communicating progress

Depending on the type of app you're developing and the number of stakeholders involved, you'll likely need to keep people outside of your team updated on how things are going. The best way to do this is to decide upon success factors and/or KPIs ahead of time. That makes it easier to communicate progress to stakeholders who aren't involved in the day-to-day development or project management of the app and to make sure the project overall is on the right track.

The idea is to choose 2-3 success factors or KPIs, so you can communicate how the project is progressing quickly and easily. Obviously, what those factors are will vary depending on the project and goals. For a beta release aimed at validating a product idea, you'd likely be focused on getting the app done and released as quickly as possible. If you're iterating on an existing app with the aim of streamlining internal processes, your goals would be entirely different.

The most important thing is that your progress markers need to be objective, rather than subjective. Something like "app improvement" doesn't give you a clear goal to aim for—whether the app is improved or not will depend on who you ask, how you ask it, etc. Compare that to "app successfully imports customer data to our system and notifies team members of next steps," which is both objective and specific.

Avoiding scope creep

"Scope creep" is what happens when you add something to the project (in this case, it might be new features or UI elements) without adjusting the time or budget needed. Once you've done the kickoff meeting for a project and have a set scope, you should avoid changing that scope, if at all possible.

Before making changes to your project scope, consider the following:

• Can this feature be added in a future version of the app?

• Is this feature important enough to merit removing something else, to free up resources?

• If there aren't any other features or deliverables that can be cut from the scope of the project, is this worth pushing back the deadline?

Of course, sometimes scope creep isn't a choice and comes as a surprise. For example, you might start building Feature B, and then realize that to fully implement Feature B, you'll need to change how Features C and D are built. Or, as you're learning to use Zoho Creator, you may realize that you'll have to approach the feature in a different way to get the result you want, which can have a domino effect on the rest of the project.

Scope creep is a much more costly problem in traditional software development, but it's still something to watch for when doing low-code development. The best way to avoid scope creep is to work closely with all relevant stakeholders and set realistic goals from the beginning. Understand the core problem you're trying to fix and make sure that everyone involved is in agreement about it. That alignment makes it easier to set reasonable limitations around the project.

If someone from another team, like your IT department, is building the app for you, gauge their level of confidence with the platform. Then, work with them to create a realistic project plan that has clear milestones and deadlines. If you're building it yourself, you can also reach out to support people, product experts, or community forum members to make sure that the product can do what you want it to do, in the way you want it to be done.

Check-in meetings

If more than one person will be working on this app, it's a good idea to implement regular check-in meetings. Ideally, these meetings will be short and focused on these three questions:

• What have we finished since the last update?

• What are we working on right now?

• Are there any bottlenecks keeping us from moving forward?

As with everything else in this article, you can scale these up or down as appropriate for your project. If you'll be working in four-week sprints and it's a fairly low-stakes project, meeting on a weekly basis could work well for you. However, if it's a larger or more complex project, daily standups might work best to keep everyone on track and alert you to any bottlenecks that occur.

Reaching the finish line and what to do next

You're done! The app is shipped, people are using it, and you get to kick back and celebrate success. But, before you move on to your next project, it's a good idea to take stock of how this one went.

Post-mortem meeting

If you're working with a team, you'll want to schedule a post-mortem meeting after the project has wrapped. Depending on how long or time-consuming the project was, you may not want to schedule this for immediately after launch—especially if it's a customer-facing app and you'll need to help troubleshoot bugs. The meeting should happen while the project is still fresh in everyone's mind, but after they've had a chance to catch their breath and regroup.

At its simplest, a post-mortem can consist of three questions:

1. What went according to plan?

2. What didn't go according to plan?

3. What can we do differently next time, after taking the answers from question 2 into account?

Getting and acting on feedback

Now that your app is in the hands of the end-users, you can start collecting feedback. If your app is being used internally, you can poll employees in the departments/teams that are using it. If it's being used externally, you can email customers who are using it, or even incorporate a pop-up user feedback survey into the app.

Here are some starter feedback questions to ask:

• On a scale of 1 to 10 (1 being least satisfied, 10 being most satisfied), how satisfied are you with this app?

• What is your favorite thing about the app?

• How long have you been using this app for?

• How often do you use this app?

• What about this app needs improvement?

• Is there anything else you'd like to share with us about your experience?

Whatever you ask, just remember: less is more! If you ask people too many questions, or if the questions you ask take too much time to answer, you'll tank your response rate. It's better to have a few highly targeted and strategic questions. What information do you need right now to gauge what's working and what isn't?

Congratulations! You've completed your first low-code project and (hopefully) learned a lot along the way. In the future, whether you're improving this app or starting on a new one, you'll be able to get things done that much faster with what you've learned.