Tag Archives: Agile

Project Management Predictions for 2016

nostradamus_portrait_vector_by_vectorportal-d5gnwxg

You don’t have to look far this time of year if you’re looking for a view into what people are saying the next year will bring. As sure as there are those making resolutions for the New Year, there are others making claims about what is to come in the New Year, for the purpose of informing, entertaining or somewhere in between. Whether you’re into technology, science, politics, or the movies, there are no shortage of predictions – some more serious than others – for what the new year will bring.

In this vein – and walking the line between being informative and being entertaining (as is generally always my goal with my posts – this time leaning more to the latter than the former) – here are my top 3 project management predictions for 2016.

Projects Will Still Have Issues in 2016

I feel ok about the lack of a **spoiler alert** on my number one prediction for projects in 2016, since I can’t image that this has come as a surprise to anyone. While a new year comes with new beginning and (hopefully) a renewed sense of ‘this time it will be different’, the reality is that projects have issues. Always have. Always will. To be clear, this is not an admission of defeat; not by any stretch. It’s simply a recognition of what is real. Despite the best laid plans, the best of intentions, talented, hardworking teams, solid processes, training and experience, there will be risks and there will be issues. Timelines will sometimes be unrealistic. Requirements will sometimes not be as clear as they could/should be and the list goes on. All that said, good teams will recognize this, plan for the known-unknowns, anticipate having to deal with the unknown-unknowns and most importantly, support each other when the going gets tough.

People Will Still be Talking About Agile

In 2001 the Agile Manifesto was created by representatives from various areas of the software development community, as a collection of guiding principles that challenged long-held notions and methodologies for application development. And while the manifesto was created in 2001, the principles and “lightweight methodologies” that it is based on were in use long before 2001, with “scrum” dating back to the early-nineties, and concepts around ‘iterative development’ dating back as early as the 1950’s.

To come straight to the point. This stuff isn’t new. Yet, it has been the sort of topic has that remained relevant over many decades. To even compare to the 2001 date of the formalization of the manifesto, 2001 was the year that Microsoft released Internet Explorer 6, Windows XP and the original X-Box; Napster had a user base of 26 million users and the Compaq Presario was the hottest new computer on the market – and you don’t hear much talk about these things anymore, do you?

For one reason or another Agile has and continues to be a hot topic in the world of software development. Traditionalists like to argue that it’s nothing more than an excuse not to plan or document requirements, while proponents are quick to dispel these notions and point out that ‘responding to change over following a plan’ and valuing ‘working software over comprehensive documentation’ results in a better product in the end. All the while, the training and certification industries are trying to make everyone ‘certified practitioners’ and ‘scrum-masters’ by spamming your inbox every chance they get, claiming that Agile is the silver-bullet you’ve been looking for.

And as if there isn’t enough to debate, I have even heard people debate over the pronunciation of Agile, as apparently that is a thing. Who knew?

So, whether it’s to defend the viability of the approach/methodology, to defend a principle or a process, or to debate its pronunciation, I predict that people will still be talking about Agile in 2016.

Project Management Will Still Not Be All That Exciting

As this article does a great job of describing – through a conversation between Leonard and Penny on an episode of the Big Bang Theory, Project Management is a bit like physics:

Penny: “So, what’s new in the world of physics?”

Leonard: “Nothing.”

Penny: “Really, nothing?”

Leonard: “Well, with the exception of string theory, not much has happened since the 1930’s, and you can’t prove string theory, at best you can say “hey, look, my idea has an internal logical consistency.”

Penny: “Ah. Well I’m sure things will pick up.”

This is to say – from my perspective – that while, there are certainly advances in project management methodologies, tools and techniques (a few for 2016 here), they aren’t often (or ever, with the exception of perhaps Agile – see above) flashy or garner much attention. That said, behind every project involving Big Data, Artificial Intelligence, Cloud Computing, Virtual Reality, or whatever emerging technology is in play, rest assured that there is a Project Manager – and a project team, working tirelessly behind the scenes.

References:

http://agilemanifesto.org/

http://www.cio.com/article/3012273/project-management/top-5-predictions-for-project-management-in-2016.html

http://blog.capterra.com/the-6-biggest-project-management-trends-for-2016/

https://setandbma.wordpress.com/2012/03/23/agile-history/

http://www.computerhope.com/history/2001.htm

Advertisements

1 Comment

Filed under Business, General, Innovation, Management, Project Management, Strategy, Uncategorized

Please Stand-by to be Processed

process2

Let’s begin with a quote from Alistair Cockburn, one of the initiators of the Agile movement in software development.

‘While a good process can’t assure delivery, and a good team can deliver despite an unwieldy process, a poor process can get in the way quite neatly’.

In case you haven’t figured it out by now, this post is about process. What it is. What it isn’t. Common misconceptions. Benefits. Implementation strategies.

What is a Process?

An established, step-by-step way of doing things, and a well-articulated set of internal and external documents and tools supporting it.

This is, of course, one definition of any number that may be out there. Another, more succinct definition (of sorts) that I’ve heard used is, ‘applied common sense’.

What isn’t a Process?

Magic. A silver bullet. A panacea. As the first quote above notes, a good process can’t assure delivery. That said, it’s a place to start. A baseline from which to begin and to continuously improve from. Even for the Agile purists that declare as part of their Agile Manifesto to value ‘Individuals and interactions over processes and tools’, are in fact rather processes driven in their own way through adherence to Agile processes and practices such as user story modeling , iterative development and time-boxing.

Preferred methodology aside, we could all benefit from a little bit of process – though not everyone is convinced.

Common Myths Associated with Process

  • Adds unnecessary steps and time
  • A form of micro-managment
  • Adds documentation for documentation’s sake
  • Limits creativity
  • Limits flexibility

These are common reasons why establishing (and documenting where appropriate) processes on a team or within an organization is often met with resistance.

On the other side of the coin, having a solid process that is understood, documented and followed can truly be the difference between success and failure on a project. And while it may not always be readily apparent from the outset, process can have numerous benefits for everyone involved. Here are 10+ that come to mind.

Benefits of Process

  1. Repeatable. Predictable. Manageable. Having a process in place will help to ensure that your delivery process is repeatable, predictable and manageable which has obvious associated benefits – as well as others explored in the subsequent points.
  2. Maximized efficiency. Minimized waste. To be able to hit the ground running on the actual work to be done vs. spending time defining the steps (the ‘how) and/or the creation of templates/documents/assets etc. to facilitate the work.
  3. Clear expectations. So everyone knows what they need to do, what everyone else needs to do, and what the timing and dependencies are.
  4. Reduces risk. By having processes in place related to the risky areas of delivery, risks are identified and mitigated early.
  5. Reduced re-work. With risks and/or issues caught earlier, the likelihood of costly re-work is reduced.
  6. Better quality product. With risks and/or issues caught earlier and the ‘how’ figured out in advance, the time and energy on the project can be focused on developing and testing the product, and the results will show.
  7. Reduced interruptions. Increased focus. Increased productivity. If there are still any skeptics, hopefully this one will help to convert them. While still having processes and steps in place related to the above points (e.g. risk identification and mitigation), an objective of any process should always be to provide more focused time for the team to do their work.
  8. Better awareness of the big picture. With a process in place and documented, everyone can see how their contributions fit into the larger picture.
  9. Cross training and professional growth. When processes are established and documented, it’s easy to train team members and new hires on how things are done to allow people to advance their career and not be ‘stuck’ having to take care of a certain task because he/she is the only one that knows how to do it.
  10. Increased customer satisfaction. Increased employee morale. With all of the above considered and addressed through the implementation of a process what works for your particular project/business unit/organization, the collective result will be increased customer satisfaction and increased employee morale, which is obviously good for everyone.

So now that we’ve seen the benefits of process, here are a few strategies for successful implementation.

Implementation Strategies

  • Alignment. When developing, documenting and improving your processes, take the time to step back and make sure it aligns with the goals and values of your organization, project and team members. Much like understanding how a work package or a test case maps back to a requirement in a delivery project, the way you get things done should also map back to individual, team and company goals.
  • Collaborate. Work collaboratively to develop your process with the people that will be using it. Seeking inputs from everyone will go a long way to ensure you have considered all of the areas and will also increase likelihood of adoption.
  • Don’t over analyze. While it’s important to not create a process in vacuum, not consulting and collecting inputs from all the stakeholders, be mindful of getting into analysis-paralysis mode trying to make it perfect for everyone. Take a page from the ‘Lean’ start-up playbook and seek to get your MVP (Minimum viable product) out there and then improve it over time.
  • Continuously improve. Further to the above point, processes should evolve and improve, so be active with looking for ways to make this happen. Process is not a one shot deal. Continuous improvement is key.
  • Understand that one size doesn’t fit all. Figure out what works for your team, your customer and your project and tailor accordingly. Consider having a step in the process to evaluate and tailor the process for each project, adjusting up or down based on factors such as the project’s size, type, technology and customer.

Leave a comment

Filed under Business, Business Analysis, General, Innovation, Management, People, Project Management, Strategy, Uncategorized