In August 2003, I started my professional career as an IT consultant at Accenture. This month marks my 20th work anniversary, a milestone that I celebrate with pride :-). Over these two decades, I have traversed the spectrum of IT project delivery, wearing various hats—developer, tester, business analyst, functional and technical analyst, all the way up to project management, test management, and solution architecture.
Yet, despite this experience, I remain consistently amazed at the challenges inherent in delivering IT projects on time, within budget, and meeting the expected quality. While software development is very rational, IT projects are very human and often irrational endeavors. While many managers stare blindly at objective metrics like development mandays or number of lines of code produced, it is essential to recognize that the development effort forms only a fraction of the entire project endeavor. Typically, the stumbling blocks in IT projects do not stem from development but rather from other facets.
How often have we not encountered projects for which the preparation phase takes months if not years, only to have the IT team being asked to implement the solution within a few months?
Once we realize and accept that IT projects cannot be nicely planned in a perfect Microsoft Project planning, because of their complexity, but even more because of all the human-factors involved in a project, we can better cope with it. Enter the philosophy of the Agile movement, i.e. advocating the continuous embracing of changes in vision, requirements and scope. Unfortunately, Agile consultants have taken over the movement by introducing all kinds of ceremonies and methodologies, which all aim to increase predictability. These slightly contradict the initial philosophy of the Agile movement. While some level of planning and forecasting remains necessary for budgeting resources, these should serve as guiding principles and not rigid as constraints.
Drawing from the successful IT project I have witnessed, several key practices stand out for effective IT project delivery:
Optimal Project Size: Strive for projects that are neither too small nor too large. Projects in the range of 300 to 600 man-days are in my opinion optimal, allowing for a dedicated team without overwhelming overhead.
Dedicated Team: A focused, dedicated team of a few individuals outperforms a larger team with fragmented commitments. This arrangement fosters accountability (everyone is accountable for the full delivery), teamwork, and focus (concentration).
Hands-On Pragmatism: Team members should embrace well-defined roles while remaining open to assisting with other tasks when needed. Clear alignment points (like e.g. daily stand-ups) and communication channels are important, but excessive ceremonies can be counterproductive (instead favor asynchronous alignment where possible).
Iterative Approach: Begin with a high-level vision, blueprint, and architecture and take sufficient time to define this well, then progressively refine the details through iterative cycles.
Short Feedback Loops: Maintain frequent communication between the product owner and developers throughout ticket design and testing phases. Too often, a ticket is put to "Blocked" and moved to the next sprint, because something is missing for a developer. Obviously, this should be avoided, as a good product owner should be able to rapidly complete anything missing in the ticket. Additionally it is highly productive if a developer asks an immediate quick validation from the product owner when he finished the story. This way most issues can immediately be identified and resolved, while everything is still fresh in the developer’s mind. Too often testing is only done at the end of the sprint, which means there is a delay of multiple days between the development and the validation of stories.
By adhering to these principles, you automatically end up with
Small, dedicated teams of 4-6 individuals encompassing roles such as a product owner, a lead developer, and additional developers.
Projects that are well-contained and independent (autonomous), lasting 4-6 months from initiation to delivery. This timeline includes 1-2 months for preparation and alignment on blueprints, followed by 3-5 months of execution. This means they should not be part of complex transformation programs, which bring too much overhead. Note that the fact that projects should not be part of larger programs does not mean the senior management should not have a clear medium to long term roadmap with several projects to execute in order to achieve a well-defined goal. The point I am making is that once a project is launched, it should work as autonomously as possible and only report on a 6-8 week basis to the Project Sponsor (e.g. in a Sponsor meeting or Steering Group).
A focus on tangible deliverables deployed in production. Once delivered the team should support during maximum 1-2 months (after-care). If they continue on a next iteration of the same product, they can continue the support. If not, there should be a clear hand-over to a support organization, so that the product team is liberated to focus on the next project.
A less strict application of Scrum methodology, as all the Scrum ceremonies create much overhead and reduce initiative, pragmatism and accountability. I am therefore a huge fan of working in Kanban style, with a prioritized back-log where everyone takes the story on top of the backlog. This approach does not mean you should not do a demo every 2 weeks, but it avoids this artificial pressure of fixing a number of stories in a sprint (while in reality there are always stories added or removed for particularly good reasons).
Balance these best practices with awareness of potential pitfalls, like
Foresee sufficient contingency: work is always underestimated and certain tasks are always missed. It is important to be aware of it and foresee sufficient contingency budget at any phase of the project. This budget should however only be used for unknown, missed and underestimated work and not for changes or for extra refactoring. In other words, stick to the scope, even if you still have contingency budget left. Most likely you will still use it later in the project. Usually (and unfortunately) the biggest surprises come near the end of the project when all the bits and pieces need to fit together.
Strive for simplicity over complexity and be aware of over-engineering, i.e.
Product managers love to create a lot of features and complex business rules to manage all the exceptions. Continuous challenging is therefore needed to ensure that all logic and all features are really needed and create sufficient value;
Developers like to re-engineer code (the code of another developer is almost always poorly written) and build technical frameworks from scratch (often reinventing the wheel). It is important the technical lead or solution architect challenges continuously the team to see if existing internal assets cannot be reused or open-source tooling or libraries are not available. It is also important to make code as modular as possible, so that re-engineering can be done gradually (i.e. when adapting a module as part of a change, do a refactoring of just that module). This gives as additional advantage, that code does not need to be perfect. If the underlying assumption is that the module will likely be rewritten in the foreseeable future, you can focus on the actual functionality of the module and on non-functional requirements, like performance, stability and security.
Remember the 80-20 rule: often the happy flow can be implemented quite quickly giving the feeling to the whole team that the finish is near. However implementing all the unhappy and exception scenarios is typically more work and always underestimated.
Automate as much as possible and never underestimate maintenance. A task that is supposed to be done only once, will likely have to be redone a few weeks later, so try to automate it as much as possible from the first time you do the task.
This also applies to testing. I am a major fan of testing automation, as it can save an enormous amount of time, not having to redo the same tests manually each time and avoiding time-consuming fixes in production due to regressions. However, it is important to be pragmatic. I have seen many projects where enormous efforts are spent on writing unit tests for all code, while the code can be much easier tested (and easier automated), when testing on a higher functional level. These types of higher level automated functional tests are also easier to understand for the product owner and are less prone to continuous maintenance (when minor changes to the code are made).
Obviously as software projects are irrational, almost every member of a project team will have a different vision of what should be done or not done to deliver the project in the best conceivable way. The above guidelines are therefore just my personal vision. In a project, each team member will have unique insights into achieving optimal project delivery. It is therefore crucial to find a way of working in which everyone feels well in the project team and improve continuously. This will give the biggest buy-in and the highest motivation to work on the project. Ultimately, motivated and skilled teams will always find a way to get the job done.
Comments
Post a Comment