Tag: Stoneseed

We invest a lot of time, energy and budget on the “self-care” of our IT projects, in terms of robust governance, strong PMO (Project Management Office) and world-class processes, etc – but do we pay enough attention to our individual or team’s self-care? Given the anecdotal stress, work-overload and burn-out in our industry, I’m thinking – NO.

How an IT Project Management team handles and learns from mistakes and setbacks can significantly impact success, not just for the current project but across your whole current portfolio – and future projects too.

A Stoneseed BA’s day will vary depending on the client’s requirements and project type. Whether it’s an Agile, Waterfall or Hybrid environment and whether its product, Infrastructure, software or digital transformation project for example. The life of a Stoneseed Ba is very varied, on this particular day, it is a for a client who is delivering an Agile software upgrade and development project.

In IT Project Management we put so much effort into choreographing our deliverables and outcomes, the part of the process that our “audience” sees, but how much thought goes into what happens out of sight, behind the curtain?

There are unexpected parallels even if, at first blush, horse trials and IT Project Management may seem worlds apart – I was struck by many similarities in the principles, the methods and the challenges. WORLDS APART Quickly, let’s compare the two.

If you’ve ever trained a puppy, you’ll know the value of a “treat” to reward good behaviour, like sitting or staying on command. I think most dogs know the word “biscuit” before they learn their own name, mind you, I know some PMs who are as partial to a bourbon or chocolate malted milk, she writes dunking a digestive! At Crufts I saw a lot of treats passed from owner to dog with a “good boy” or “good girl”. Rewards are vital to the process.

Experience and anecdotal evidence suggest that Bex isn’t alone in seeking a little bit more. In many organisations now, IT project teams feel that the necessary fixed scope, set budgets, tight deadlines, limited resources and defined roles and responsibilities, leave little or no room for experimentation and innovation. The thing is, if you’re getting the results, do you need the added sizzle of innovating? I think that you do.

The trainer was explaining the team’s fairly unique binary approach to scrum sprints, which effectively boils down to them having two duration categories – A) one week long and B) three weeks long. The new hire found this interesting and enquired about the reason behind this approach. In her last job, length and number of sprints would be decided at a goal setting meeting, a twelve-week scrum project could have 15–20 Scrum sprints, which could be as short as a handful of days and as long as a month. So, “Why?” seemed a reasonable question but it was met with either blank expressions or an unsatisfactory explanation. The trainer did not know, nobody on the team could answer either.

Isn’t it beautiful when an IT Project team execute and implement with total cohesion from top to bottom? When colleagues become team-mates, and when...