Project management for software development of patent management software, trademark management software, IP software or other software

Monitoring, observing and tracking a software project can be a challenge. First of all, there are some really great agile methods to create a framework that allows everyone to at least get started with a framework. One of these agile methods is of course SCRUM. Agility in software development has been proven to lead to more flexible, faster, more transparent and more user-oriented software solutions than previous methods, such as the waterfall method. Of course, there are areas where nothing works without the waterfall method, such as space development. But we don't want to deal with that here.

Back to our agile programming methods. The problem with all these wonderful agile project management methods is that they require a certain level of commitment and expertise that many managers don't have or simply don't understand. However, you want to know what you need to do on the fly, so to speak, without having to think about it too much, without having to get involved too much, in order to record a successful software development project as a result. For this bird's eye view, I can perhaps give a few essential tips, but I generally recommend taking a course in agile project management methods to avoid belly landings. Nevertheless, here are a few tips:

1. always consider the requirements you receive from two perspectives,

a. The first aspect is the importance for your customer and thus the importance for all your customers (experience shows that everything that is particularly important to one customer is usually also important to all other customers).

b. The parallel aspect is the importance for your company. Do the requirements to be programmed correspond to your business objectives? I am deliberately not asking whether you have defined clear corporate goals that are transparent for all parties involved, because that would be cheeky.

2. sort the requirements according to importance.

3. communicate with your customers what (rough) timeframes will probably be needed to implement their requirements. Remain transparent. If possible, do not promise fixed delivery dates if you cannot keep them.

4. transfer the software programming work that has now been handpicked in the above order into a project management system in modules that are as small as possible but coherent and comprehensible for everyone. This could be Microsoft AZURE DevOps, for example.

5. get your team involved. The team should consist of people who understand what the requirements are, who understand what the customer benefit is and who understand what the importance is for the company and for the customer and in what order the individual elements should be implemented.

6. let the team do their work and give them a "free hand". However, set up meetings at regular intervals at which you understand the team's work,

a. what the team is currently working on,

b. what the team is not currently working on,

c. why the team may deviate in some order of importance,

d. what you can do to help the team maintain the order of importance and

e. whether you may need to contact the customer again if the team's prioritization needs to be changed for understandable reasons. Experience shows that many business appointments can be extended to other dates after consultation with the customer, as long as the customer is contacted in good time before the agreed date expires and the process is transparent.

‍

‍