Sorry for late response, I've been out on the farm for a week. On 19.05.17 07:22, Piers Rowan via luv-main wrote: In my 30 years of managing software development teams, we used products like "Microsoft Project" for task management. First, I architected the system, then the team iteratively refined that to generate a "Work breakdown Structure" in which a leaf task might have a tree address of e.g. 17.23.42. Then we estimated the time to implement each leaf task, and let the project management software give us a fright on the total. I always added 30% to the team's estimates, as we are always optimists. After linking task dependencies, and inputting available resources to the project management software, I'd end up with a nifty Gantt chart, with the critical path clearly identified. After letting management choose whether they'd let me hire additional contractors, or just endure the development lead time, I started development by handing out initial tasks - granting only 90% of the time allowed. That accumulated a 10% additional reserve to hand out when gremlins surfaced. (That was rare. We developed embedded systems, and I kept the designs pretty darn clean. The developers were very good, with years of experience.) The "Work Authority" for each task included task requirements, especially relevant specification clauses, and any resources which might be needed/useful. Given that it can be that the first half of development takes 90% of the time, and the second half of development takes 90% of the time, I never asked a developer "What is your current progress, i.e. % complete?", instead asking "How much more time do you need to finish?". Now, instead of tracking % of allocated time consumed, until 90%, then jamming there for an indefinite period, the answer provided prediction of task overrun before it had happened. Using that system over the last two decades, I never had a project run over time or budget. (Given the liquidated damages contract clauses we sometimes faced, the former often wasn't an allowed option.) As for cobbling up some sort of "burgers & fries" ticketing system to hang off the developers' IDE, how do you handle the dependencies? How do you show delivery slip five months before it happens? (So you can fix it while it's still possible.) At the two companies, a German and a Japanese global corporate, we just went with "Unix is the IDE". Vim & exuberant ctags, cvs, and I forget the name of the bugtracker, were more than sufficient to efficiently and effectively wrangle projects of up to 8 man-years in C & assembler. (And across various targets, including 68k, PowerPC, V850, AVR, we used the GNU toolchain pretty much exclusively over the last 15 years.) We were helped by a documented and audited development process - a vital part of the quality system. If either internal or external customers wanted a requirements change after the document had been signed off, I stopped development, we analysed the change request, and reported the additional development cost and the delivery slippage. Then they decided whether they really hadn't known what they were doing when the original requirements were defined. That worked splendidly at the German firm, but I remember a meeting in Dallas, where the American marketing chap wanted to change around 30% of the requirements a couple of months before delivery. We didn't see eye to eye on that one. To me the above is just recounting what worked best on million dollar projects, but it might be perceived as a rant, since it doesn't fit the modern Point-n-Grunt rat-wranglers interface idiom, where font & colour are considerations, it seems. In conclusion, I'll suggest that it's less important what an engineer uses for a hammer, than how he whacks with it. Erik -- "Walking on water and developing software from a specification are easy if both are frozen." - Edward V. Berard