It’s really not all that simple.
Yes, maybe some apps are simple enough. In fact, they are so simple that you wouldn’t quite call them a “project”. But that’s where the danger lies. At what point does it count as complicated enough that you have to think differently about them?
The real trouble comes when some non-IT people get carried away and, not wanting to wait for or depend on their IT department, decide they are quite qualified to run their own IT project.
I have seen specs put out, or the lack thereof, that are simply horrifying. How can the scope of works be not defined? How can it be that deliverables are not specified? How can payment schedules not be linked with clearly defined milestones? How can warranty and maintenance services not be accompanied by service level agreements?
We’ve done business with a certain big-name IT company that, even for a very simply clear-cut “supply and deliver” procurement, they have a longish dozen or so pages of statement/agreement for the Scope of Works. It’s just supply and deliver, like you buy PCs from Dell or Apple. But they have tons of legalese about responsibilities of various parties, when and where does title to the property get transferred, insurance, etc.
How much more important that would be for an IT system project?
Some IT projects will fail. There could be many reasons, and those reasons might not have anything to do with mismanagement of the project. Stakeholders in the project need to know what happens when they walk away from the project. Who owes whom what, who gets to take what, etc.
That’s how greatly mistaken some non-IT people are about the complexities of such projects. That’s how they get screwed over by IT vendors. It’s not that the IT vendors are being unscrupulous, it’s just how things work.
It’s actually not greatly different from, say, in the building and construction industry. If the contract did not specify something, then it is not included. If the contract did not define something, then the contractor will define it for you.
There are no doubt lots of building codes, electrical codes, fire codes and other sorts of regulations to make sure things are up-to-standard. But there’s so much more that you need to nail down.
The difference is that you’d always get a “professional” to run a building and construction project. In IT projects, sometimes the inexperienced layman think they are suitably qualified to run the project.
Sometimes, people from a different trade think they can apply their practice, from their line of work, to IT projects. It’s not that IT projects are more complicated, but some things do work differently.
For example, in construction work, it is easy to monitor progress. That’s because the work is visible, measurable, and quantifiable. You can’t do the same thing with IT projects, particularly when it comes to software development. Progress in software development isn’t quite so measurable. Sure, some people will bravely collect meaningless numbers like man-days worked. But at some point when you come to integration, UAT, or whatever, and if the thing flops, it can flop so badly you got to go back to the start.
That means you could go from “95% complete” back to “5% complete”. Just when you thought you’re almost done, you’ve now only just started.
Once upon a time, someone from “another trade” asked me, can I expedite my project? We were on-time, but we were late according to their schedule, because someone gave us the wrong schedule. So they tried to suggest things like, you know, adding more manpower, work with customs to expedite clearance processing (for stuff shipped from overseas), get “higher authority” to push things through faster, etc.
It’s not like I don’t know how to do all those things. But you know, you couldn’t just add 2x manpower to a software project and expect a 50% reduction in time required. This is not like laying floor tiles. Double the manpower, of course the flooring gets completed in half the time. (I know there are other constraints too, but generally, timeline can often be quite flexibly adjusted.)
There are several aspects of IT projects that make them unique and inherently different from some others may feel are similar type of projects. One thing I’ve learnt is that managing IT projects is a lot about risk management. IT projects are also not all about, nor even mostly about, the technology, but also a lot about managing change, process re-engineering, etc.
Sometimes people forget that even in “smallish” IT projects (and hence assumed to be simple and straightforward), there may be elements of humans involved that could critically affect the success of the project. For example, do users actually want the project or not? Great IT projects have failed not because of any technology element, but simply because of human factors.
Easy is definitely not all that easy.
Back to the original topic. The point here is that often times what seems to be a simple application development project could go far beyond simply getting a part-time programmer to write some web program. There are many issues to think about. As an IT person, a natural thing to be “worried about” when someone runs off running their own project is… well, who will run the system after that, and who will be responsible to maintain and update the system? Who is responsible for support? What are the backup plans, disaster recovery plans, etc? What service levels are expected by (or promised to) users?
Yes, yes. So many questions. But they thought it’s just a simple app.