We believe that implementing an IT-project should not take longer than 4-6 weeks after the ⇨ project scope has been determined!
By implementing the project we mean
- building the prototype
- deploying the productive version
If we believe the 6-weeks condition could not be met given the existing project scope, we discuss with our client how to prune the set of project objectives in order to be able to accomplish the 6 weeks target.
⇨ Features left out will be addressed in another project.
- Buy-In of management will increase
- Motivation of involved staff is preserved
- Value is added quickly
- Commitment of management likely to fade
- Buy-In of involved client's staff will decrease
- Costs (money + resources) likely to run out of budget
- Likelihood of failure increases dramatically
Is complying with the 6-Weeks Rule realistic for large IT-Projects?
This question is best explained by example:
A client of ours, a venture capital fund of fund, decided to become fully digital in all of his workflows. This included data maintenance, reporting and running a customer portal which provides services to investors in the fund.
Seems like a big task, right?
Some banks will spend millions of Euros on similar projects.
If they are lucky, after a few years the project comes to an end.
How we did approach the mission ...
Identifying Pivotal Points
We identified that setting up the fund's database would form the foundation for all further achievements. At the same time we wanted to have something quickly usable and visible for the client who was not experienced with regards to IT-Projects.
We decided to use the tool
The tool allows to ⇨ model a company's database by drag and drop.
- With Xalimo TeamPlay® we were able to create models for
- the fund-of-fund,
- the target fund,
- the equity holding,
- the investor,
- time series data
Xalimo TeamPlay® provides many ways to capture and maintain data. Among these methods one is to enter data in a report format. This came in handy as producing a report was part of the project objectives anyway.
- Just like filling-in a PDF-form the user can capture all the information he or she wants to share with investors.
- By clicking on a button a PDF-Report is being created, ready to be circulated among investors
- When the next report is due, based on the last report and recent developments the new report is being drafted and published
- As a side-effect the above modeled data structure was populated with actual data.
Having chosen the right software tool and identifying the structure of the task to be solved was key to comply with the 6-weeks-rule:
Name of Project: ⇨ Modelling the Company's Database & Quarterly Reporting
- Modelling the companies data structure.
- Maintaining data and documents on the fund, target funds, holdings, investors, transactions on the various investment levels
- Designing and layouting the quarterly report (corporate layout, charts, logos)
- Aggregating data across the various levels (fund-of-fund, target funds, holdings within those, views on markets and investments)
- Being able to provide PDF-reports to the fund's investors,
- Avoiding any kind of redundant manual entry of data
- Provide convenient methods of maintaining data
- Keeping records on any data changes regarding content, time of change and who did the change
Out-Of-Scope: ⇨ Populating the Company's Database (this was the client's job)
Duration of Project: 5 weeks
Costs of Project: Less than 15k Euros
The Second Project
You will not be surprised to learn that setting up the customer portal would have made the second project.
With the company's data structure and data at our disposal it was not difficult to tap into the data and provide services and information to investors based on their access rights through a client-server web application.
Duration of Project: 4 weeks
Costs of Project: Less than 10k Euros
Isn't it just Words?
You might argue that dividing the initial project into two parts is just semantics. We do not think that this is the case for the following reasons:
- Each project could be stand alone*. The customer might decide to postpone the second project to the next year or even to skip it. He still could utilize the features provided by the first project.
- Project one and two are interchangeable* regarding their order of implementation
*as long as the first project includes setting-up the database
Are there risks to this approach?
We have heard the argument many times:
»When thinking and, as a result, implementing separate projects, isn't there a chance that the overall goal might not be achieved due to flaws in the design of any of the single projects?«
The answer is: Yes could be. Worst case we need to re-design and refactor an involved project implementation in order to fix flaws which might lead to extra costs. Still the advantages like overall cost-savings, extremely short time-to-market will outweigh the costs and risks of giant-projects by far!
The approach we take does hence qualify as Agile IT Development