Experience is the key
It is equally possible that he understands his job well enough but his management is the clueless part of the equation and they are placing impossible goals for the team.
Well, that may be so. The point I make about his not being a project lead until he was made "studio director" is that he had
no practical software development leadership experience before. That's critical when being given impossible deadlines, understanding the implications of a decision related to schedules or staffing or manpower, even as simple as understanding the effect of sick days on a project schedule. When given an impossible deadline, one can and should refuse to subject the team to failure. His leadership experience in the Army should have taught him that, which makes me wonder if he really led people even in the military.
That aside, though, he flat-out
lied in the podcast. Perhaps he was ordered to lie, in which case his inexperience tells again - never lie, either withhold information or tell the truth. But to say Silverlight (for example) was the choice because it allows them to develop for mobile platforms is disingenuous, a lie, or a display of ignorance because
Silverlight doesn't work on Android or iOS devices.
The fact that the data (remember, the material they wanted to protect against privacy) is unprotected in the Silverlight client is damning as well - either he knew it was unprotected and allowed it to ship, which undermines the key justification for an online-only CB, or he didn't know it was in there which means he doesn't understand his application.
Again, with experience he knows what questions to ask - but he has no practical software development leadership experience, and so doesn't know or was afraid to ask the right questions.
Now let's say he
was given a "ship or die" order that resulted in the buggy software we see being released on 16 NOV. This is speculation, but given no professional would release what was released except under duress and given the clearly cascading slips from Essentials release to October to November, my take is that management no longer had confidence in the team's ability to predict their own schedule. Given all the other evidence that points to lack of experience, this is the result of his (nor anyone else on the team's) inability to do what's called a "work breakdown structure" (a break down of the tasks required) to figure out what remains to be done to call the project complete... or at least hit a milestone like Alpha or Beta. (This also requires an understanding of the requirements for a milestone...)
To be clear, the alternative to not being able to do a work breakdown structure is not being
willing to do a work breakdown structure.
Of course, it's also entirely possible that they did a WBS but weren't able to estimate properly... which, if it happened, speaks to the inexperience of the entire team as well as the studio director and the project manager, since an experience project manager-type can start accounting for bad estimates.
I
am a project manager by trade. I am no Old Timer, having only been doing this for 16 years. I kick the tires of developers to see whether they are good enough to sub-contract and to analyze their process to see where it breaks, and I do continual process improvement on my own projects to see what's wrong and what's worth doing again, or more of. I have screwed up projects and swung in on a rope and saved the project from falling into lava, and while I haven't seen it all I've seen plenty.
This has many of the hallmarks of a screwed up project, mainly in terms of process and project management.
- Ket
