Generally, according to managers, software development projects are all urgent, but the reality is that some are more urgent than others!
Typically, in agile mode, we talk about 3-week sprints following sprint 0 which is the initial “definition” sprint. However, we are encountering more and more situations where the client requires Agile+++ development or, if you prefer, projects that require accelerated Agile development… very accelerated!
We’re talking about one, two or three very short sprints (one or two weeks maximum) with well-defined deliverables and expectations.
Are the demands unrealistic? Was the planning deficient? That’s another story… One thing is certain: in Agile+++ mode, there is no room for “red tape”, we want competent resources that collaborate with each other and are motivated to deliver!
And how does all this get executed? So, let’s start at the beginning.
Opportunity makes the thief
There are several reasons why a client will use an external firm for software development.
The first, and one of the most important, is to find expertise. It will be a company (of any kind) that does not have the internal expertise needed for a new and urgent development project.
The second is usually a lack of capacity:
– It may be a large company with its own IT department but whose department simply doesn’t have the time to do that specific IT development project. On the other hand, collaboration with this team will be essential.
– It could also be a small business with no in-house development team or limited resources.
The third one could be called “there’s fire”:
This is the case of an organization that has a change imposed due to a regulatory, policy or other change. For example, this would be the thorny case of a large company that is conducting several development projects in response to a change in technological direction, some of which are dependent on others, and that needs to synchronize the deliverables of 3 or 4 simultaneous development projects; it will therefore call upon an external firm to carry out one or more of these projects.
There’s no point in running… just leave before the time!
Experience teaches us that the best of plans does not hold up to reality, in IT more than anywhere else, but the idea is to put all the chances on your side, especially when deadlines are tight.
Earlier, we talked about competence. To increase the chances of success, you must first rely on one or more good analysts who will be able to define the scope of the project and the expected deliverables in black and white. And stick to it, comply with it!
And for that, you’ll need a good Project Manager and a good Product Owner, two key positions in the success of any IT development project.
Of course, developers must be experienced and motivated.
Key factors for a successful software development project
It doesn’t get any more basic than that; you need to put in place good tracking tools that will generate good metrics, meaningful measures such as calculating the project projection: hours completed to date + remaining to be done.
You need to set up good communication; that is, create good communication channels:
– Advocate the SCRUM agile method
– Involve a decision-making resource with enforcement power
– Identify a resource with knowledge of the company’s business intelligence (probably the “product owner”)
– Plan short meetings with the project’s decision-makers at a determined frequency to communicate the project’s true status
– Plan a crisis team (CTO, IT director, project manager) to be able to react quickly
– Capitalize on transparency: you have to be able to say what is going on (quality not up to par, unrealistic expectations, refusal of change requests, etc.), not be afraid to tell each other the real story
Post mortem… for the benefit of a future software development project!
Surprisingly, few project managers realize this, but it is necessary to prepare for the retrospective analysis (debriefing) during the project.
We are talking about Technological Intelligence here. The key people of the project must have the reflex to make an inventory of the notes, minutes, critical decisions (architecture, UI, functionalities, etc.) taken during the project in order to evaluate the impacts that will potentially turn into tasks and recommendations in the framework of later stages or future development projects.