A couple of days ago, at a Sure Step 2010 training at Sundsgården, Helsingborg, Sweden, while students were preparing to take the exam, one of the students asks me where she can download Sure Step 2010. I give her the link, but she tells me: “No, that’s Sure Step 2012, I’d like to download 2010”.
That came as a surprise. “No way” – I say – “It hasn’t yet been released.”
Or has it?
And then I check, and almost can’t believe it – it’s really there. I completely missed the tweets, the Facebook announcement, the LinkedIn discussions. It seems that I’m not particularly social nowadays. A quick check of Twitter shows me that there wasn’t too much buzz around it, and most of the blogosphere simply redelivers the same content, which either comes from the official announcement (which I also missed ) or from whoever blogged first.
Instead of giving a simple “excited” redelivery of the announcement, here’s my take on Sure Step 2012, what’s new, what’s not new (both sadly and thankfully).
Almost exactly two years ago, incited by a comment from a reader, I wrote an article in defense of Sure Step: Read My Lips: Why?. The point was: is Sure Step a new methodology, or is it just a wheel reinvented?
After having taught about a dozen of Sure Step courses all over Europe (and just preparing to take my flight to Århus, Denmark to teach the next one), I’ve decided to prepare an overview of how Sure Step aligns with other methodologies. Students often ask me about this, and often come with previous knowledge of existing methodologies. Being able to map your existing knowledge to Sure Step will be of great help to learn and understand Sure Step in the future.
So, here is a little reverse-engineering of Sure Step from methodology point of view, and an overview of how it aligns specifically with MSSP, MSF, PMBOK, Scrum and MOF.
Project plan. A fancy term we all like to use. But believe it or not, most of us don’t even know what a project plan really is.
I don’t know why, how and when it came to be that in IT we started using the term project plan, but whatever the origin, the term we use is somewhat incorrect, and when attached to what we often attach it to, it’s downright wrong.
Many project management authorities assert that from project management stance all projects are equal. I dare saying that some projects are more equal than others.
In my last post, I argued why I believe software (and ERP) projects are different. But something came to my mind today, and it’s really an important differentiator of ERP projects from other kinds of projects.