Skip to content

Low-Code Projects — A Project Manager’s Perspective

Technology

Oct 25, 2021 - 5 minute read

2027 Low Code Projects Blog 416X300
Objectivity Innovative leader in technologies

Our specialty is designing, delivering, and supporting IT solutions to help our clients succeed. We have an ethical framework that underpins everything we do. Our underlying philosophy is that every client engagement should result in a Win-Win and this is supported by our four values: People, Integrity, Excellence, and Agility. Our clients are at the heart of our business and we are proud to form long-lasting working relationships, the longest of which is 29 years. Our goal is to continue to grow our business whilst remaining true to the ethical framework and values on which we are founded.

See all Objectivity's posts
V01 2053 Cloud Checklist Res 385X300

Share

About Low-Code

Low-code technology is gaining more and more popularity on the software development market. Gartner estimates that by 2024 low-code application development will be responsible for more than 65% of application development activity. The worldwide low-code development technologies market is projected to total $13.8 billion in 2021, an increase of 22.6% from 2020, according to the latest forecast by Gartner, Inc.

At Objectivity, we deliver projects leveraging two market leading low-code platforms: Mendix and PowerApps. In this article, we’ll use our experience to discuss a Project Manager’s perspective on working with low-code.

Setting Up and Delivering a Low-Code Project

At first glance, low-code platforms may seem to be the perfect choice for prototyping and building Proof of Concepts (PoC). Even if this is your first impression, these platforms are also great tools for creating fully functional solutions. The results are delivered in a fast and cost-efficient way, providing the client with a tangible proof whether their idea for an app is going to fly and turn into a regular development project.

When planning your project, it’s worth considering the length of sprints and intervals between demos. Low-code’s rapid delivery means new features will quickly be ready for a demo. Therefore, shortening the sprint duration from two weeks to one may be a good option. Moreover, having more than one demo within a sprint will reduce the user feedback loop. Alternatively, ad hoc syncs with the Product Owner or business SMEs to walk them through new features may be a way to go. Such an approach will help you keep them engaged from the beginning of the development process, as long as they will feel comfortable with less-structured ceremonies.

When you set up your development team, it’s good to remember that rapid development only means that acceleration is to be expected in, that’s right, development activities. The amount of effort needed for the requirement analysis and testing isn’t decreasing. A multiskilled team with open-minded developers who don’t fear performing tasks related to requirements preparation or testing (but not her/his own code) can make the agile magic happen in the project.

Common Pitfalls

Our experience shows that issue investigation might be one of the most problematic and time-consuming activities in a low-code project. Usually, after spending more than 2-3 days on the investigation and finally reporting the issue to the platform provider, it turns out it that the problem is, in fact, platform-related. Therefore, it’s important to build awareness within the team that the cause of an issue may lie within the platform. Keeping this in mind will pay off, as such cases will be spotted early, and the investigation won’t consume too much of your team members’ time.

Low-Code Team Set Up and Communication Styles

Low-code software creation doesn’t always mean less work on software development overall.

It’s important to find the right balance between the team maturity, solution complexity, the number of user stories and the pace at which they are created. It will enable you to define the required level of detail, which is key in every project.

To allow developers to work faster and without unnecessary impediments or blockers, the Business Analyst (BA) needs to provide them with the requirements’ description as soon as possible. A mature development team can, however, work effectively based on less formal and more generally described requirements.

Sometimes, a simple mock-up prepared e.g., in MIRO or a similar tool (or even on paper) will be enough to implement a requirement. In many cases, mock-ups prepared by developers directly on the low-code platform as the result of their discussions with the BA or even during such discussions, will be good enough as well.

The less mature and experienced the development team, the more detailed and precise description is required. Business complexity is another indicator which may complicate or simplify the way of documenting the requirements.

The fast pace of development (known as rapid development) also impacts testers. They are busy almost from the beginning of each sprint as features are provided dynamically, and user stories contain less content/requirements compared to the traditional development.

With all this in mind, our optimal scrum team would be built of approx. 4 MX developers, 1,5 BA, and 1-1,5 testers.

Client Perception

When our clients face the decision which platform is better for their project: a traditional one or low-code, they usually take a few factors into consideration. Firstly, the potential cost of the project and secondly — the timeline, especially if they’re going to order a completely new system which will allow them to automate their processes.

We noticed that there’s no significant difference in the perception of the clients who already had experience with low-code platforms and those who are about to use them for the first time. They often expect that all of the features will be possible to implement ‘from the standard box’. However, if any customisation needs are identified, they will be associated with additional expenses. Therefore, it’s better to prepare the client for such a scenario and help them avoid an unpleasant surprise.

In most cases, there’s no possibility to avoid customisation. It often happens that the usage of standard controls will require changes in the client’s processes — and that may simply be unacceptable. That’s why the team should include an experienced Product Owner (PO) on the client’s site, who knows not only the business processes but also understands the benefits and limitations of low-code platforms. Such a PO should be able to assess the value of customisation and be powerful enough to convince the business to reject customisation ideas if they don’t bring the expected value to the product.

During client negotiations, it’s also worth highlighting the different types of contracts that could be signed. We should point out that if the client prefers a Time & Material contract, they should consider possible contingencies on their side to avoid unpleasant surprises during the delivery phase.

Summary

Keeping all advantages and disadvantages of low–code in mind, some people may try to judge if low-code projects are easier or harder to manage than the traditional ones. We believe that there’s no simple answer as there are too many variables which may impact the judgement. They include the aforementioned team maturity or the Project Manager’s experience. That why it’s very important to approach the project team setup carefully, as not everybody likes to work in a fast-paced delivery environment.

On the other hand, clients appreciate the fact that they can see the results of their refinement discussions rapidly, play with them after a demo, and make comments or requests that will be delivered within the next sprint. All of this gives the client a real influence on the final solution and implementation scope.

From a Project Manager’s perspective, such situations give us a lot of satisfaction and a sense that we’re doing things the right way and quickly, making our clients’ lives easier.

In a word, we can say that the low-code approach presents many opportunities to both sides.

About the Authors

Renata Woda
Senior Project Manager

Renata is a seasoned Project Manager with experience in software houses and banking institutions. Privately, she’s a fan of outdoor activities, especially if they’re connected with travelling and scuba diving.

Wojciech Paryna
Project Manager

He is a Project Manager with over 8 years of experience who enjoys supporting teams with a servant leader approach. In his free time Wojtek is a big fan of Robert Makłowicz cooking series and handball (in any variety) as a former player.

V01 2053 Cloud Checklist Res 385X300
Objectivity Innovative leader in technologies

Our specialty is designing, delivering, and supporting IT solutions to help our clients succeed. We have an ethical framework that underpins everything we do. Our underlying philosophy is that every client engagement should result in a Win-Win and this is supported by our four values: People, Integrity, Excellence, and Agility. Our clients are at the heart of our business and we are proud to form long-lasting working relationships, the longest of which is 29 years. Our goal is to continue to grow our business whilst remaining true to the ethical framework and values on which we are founded.

See all Objectivity's posts

Related posts

You might be also interested in

Contact

Start your project with Objectivity

CTA Pattern - Contact - Middle

We use necessary cookies for the functionality of our website, as well as optional cookies for analytic, performance and/or marketing purposes. Collecting and reporting information via optional cookies helps us improve our website and reach out to you with information regarding our organisaton or offer. To read more or decline the use of some cookies please see our Cookie Settings.