I don't know how others do this, but having just experienced this for the n-th time in another different company (it feels the same in all big companies), it seems to deserve some notes.
In my experience, project development typically works like this:
- A general target is set. ("Wouldn't it be cool, if we could do this and that automatically? Currently it involves a manual process, which goes over weeks. It could save a lot of work and we'd possibly have it done in minutes, or at least days?") The target is agreed upon, a sponsor is found who agrees to spend some money.
- A project team is built. The project team usually involves a project manager, business people from all affected departments, including operations (which will usually have nothing to do with the thing until and possibly even after the first months of productive use). Finally, there are the people who will actually be writing the documents on requirements, architecture, and whatever else seems to be required. Let's call them the consultants.
- The consultants are usually very clever people, or at least some of them are. In most cases there even is at least one so-called "software architect". As the term indicates, consultants are rarely internal staff. And if they are, they are rarely bound to a particular department, but hopping from project to project. Very cleaver people are rare and sought after everywhere. The sooner they can start a new project, the better. OTOH, this means that they don't have a deep knowledge of the business topics involved. In other words, a lot of discussion between the consultants and the business people will be required. The consultants have to learn to translate the different languages of the business people into their own terms and, not less important, they must translate their own terms back into a language that the business people understand. (The last 2 years, I have been working in a project, where the word "order" has at least 4 completely different technical and semantical meanings, depending on the context.)
- The specification evolves over time. Initially, it was expected that fixing the specification (including agreement from all affected departments) will take 6 months and another 6 months was expected for implementation. That means go-live in one year. Of course, given all the required discussions, changes, additions, and whatever, the specification won't take 6 months, but 9 months, one year, or even more. You're lucky, if the estimated time for implementation remains at 6 months: I've seen it happening that the additional time for specification was cat from the implementation time frame. No problem, because the specs are now so good, thanks to the additional time, that the implementors can save the same amount of time.
- Finally the specs are done. Let's assume that the estimated amount of work for implementation is 2 man-years. Now we can estimate the time that it takes quite easily: With 4 team members, it will take 6 months. But we don't have time. We'll have 6 team members, hence only 4 months, so we can keep our targets.
You think, this is funny? Just ask yourself: When did you see it the last time, that one or more additional team members were hired, if the project wasn't on schedule.
- If we are lucky, the six team members are at least average programmers. It is rare, that a "very clever" one is included. Very clever people are too rare to stay in the implementation teams. They are pulled off to work at presales, as "software architects", or "business consultants". In bad cases, two or three of the team members are clearly below. Either that, or they come from a less technical world (main frame), have been working in a simpler environment for 20 years and are now exposed to a world where you work with 7 servers or worse, including frontend, backend, database, LDAP, and at least three different queues or other external services.
The team members have "clear assignments". After all, there are business requirements, formal specifications, and whatever you might ask for. But, of course, they are also external staff, or at least members of a different (IT) department. In other words, just as the consultants before, they need to learn and understand the business topics. In theory, you *can* read, understand, and memorize those thousand (or even more) pages of specs. In practice, you are expected to do this while already implementing. At least, I can't remember a projects GANTT diagram, where the first two weeks have been reserved for "reading".
In other words, let's face it: In particular in the first weeks, implementors are clearly overstrained. And there is few guidance: The consultants who wrote the specs, or at least most of them, have already been assigned to another project. I can't remember a case, where a specification writer has been part of the implementation team, with the exception of yours truly. Of course, they are available for questions. But the first technical decisions, apart from "we will have those 8 different modules running on 3 servers with application server X and OS Y (all choosen by the big companies inquisitio..., pardon, central IT department, except the third server, where we are forced to use application server, or OS Z)" (Usually written down in a document called "software architecture", together with the promise that the application will scale well, by "simply" using more than one instance of X and Y per server...) are usually made
- at a time where the schedule is already heavily pressing
- by people who haven't yet a deeper understanding of the project
- by people who aren't considered excellent
Take that together with the fact that these first decisions will have heavy impact on the projects future.
Another matter is the teams structure. Ideally, a project would start with one or two, preferably good, programmers who lay the general architecture. In time, other programmers would come in, taking up what's there and with the possibility to learn quick by asking the initial. After some weeks, it would be possible to assign a dedicated field of work to a new programmer: Most API's basically fixed, at least dummy implementations of interfaces to other services, and so on. In other words, an environment where even an under-average programmer has a chance to do good work. Perhaps the specs might even be helpful at that time, because one of the initial programmers can tell you know exactly where to implement the stuff, which API's to use, and so on. The specs have become applicable.
I really wonder, whether things couldn't be different. Suggest the following:
- Let's add one, or even two, very clever consultants to the specification team. Of course, that means that the sponsor's initial costs become bigger.
- The task of the additional people would be two-fold: 75% implementation, 25% following the specs. The latter means that they should participate in the most important meatings, follow the communications via mail, or whatever, and read the documents.
- Implementation means, at this time, to develop something that is as good as possible between a click-dummy, or PoC, and the real target.
- In case of a real implementation, the initial implementors ought to stay
in the project for at least 6 months.
Of course, the chances are, that a good part of this initial implementation will be thrown away later on. But, I'd bet that a good part of work could be taken over. Not to underestimate the amount of input
- from the technical side (the implementors) on the spec writers and
- from both spec writers and business team on the implementors
- the much greater momentum that the real implementation will have
- the better chance to have a good estimation of the implementations costs and schedule
I believe, it is because they are much closer to my idea of a project when companies like Google, or Apple, can be innovative, and more innovative than others. Doing things is never the same than planning. Most likely, I'll never see that happening...
