Skip to main content

Tag: Strategic & Business Management

5 Step Strategy for Effective Project Planning

Written by Sebastian Bos on . Posted in Articles. 4 Comments on 5 Step Strategy for Effective Project Planning

Project planning is an art – no two projects will ever be the same, and as such each plan and approach has to be customized according to the circumstance. If the plan isn’t an effective one, the project has less chance of succeeding.

For instance, a key part of planning involves ensuring that the company has the resources, capabilities and capacity to complete the project as well as identifying any potential obstacles that could affect its progress. Additionally, progress must be predicted so it can be tracked for deadlines, and contingency plans must be developed.

Related Article: 4 Steps to Project Planning Success

With this in mind, you should try and devise a project planning methodology that you can use to check off various aspects of your plan before you submit it. This will differ for every project, but as a general strategy or checklist to be consulted when planning a project, it could be an invaluable help.

Make sure you have all the skills you need

As the project planner, it is your responsibility to ensure that your skills are up-to-date so you can do the most effective job possible. One area in which a lot of project planners lack the necessary level of skill can be in people management, as failing to deal adequately with the different demands and requirements of stakeholders and team members can lead to project derailment. With this in mind, you should ensure that your skills are up-to-date in areas other than the likes of analytical thinking and time management.

Alternatively, you could surround yourself with people who do have the skills you have yet to develop. This will create a balanced team of planners and, while you have the final say on any decisions to be made, you will be able to draw on the skill sets of multiple people rather than having to shoulder the responsibility yourself. This is especially important for larger projects.

Understand the scope of the project

Every decision you make when it comes to the project plan will stem from your understanding of the scope of the project and the work involved. You should ideally have been involved in the project bid so you should already have an understanding of the scope. If this isn’t the case, it is up to you to collate the relevant information and decide whether the objectives outlined in the scope are achievable or not.

This is where those people skills are utilized – if something isn’t achievable (because of resources, deadlines or anything else), you need to tell the relevant person and subsequently face pushback from them. Negotiation, conflict resolution, and general communication skills are therefore extremely important here.

Get the basics right

The “basics” of a project plan refer to the fundamentals – the building blocks of a solid plan that are vitally important to get right to give the project the highest chance of success. Stick to “who, what when, how” questions such as:

  • Who will design, create and review/test the deliverables?
  • What form will the deliverables take?
  • When will they be delivered?
  • How will the work be done?

Once you have answered these questions in a general way, you can then be more specific and begin to work out things like timelines, risk assessments, and contingencies.

You should also now define the priorities for the project – what needs to be done first so that other work can commence? What resources do these initial jobs need to get the project off to a good start? Once you know what the initial steps are in their most basic terms, you can begin to think about more complicated things like work breakdown structures and baselines.

Review it frequently

It’s obviously not enough to devise a final project plan and assume that it will progress exactly as you intended. It needs to be reviewed almost constantly along the way so you can assess its progress (for instance, actual costs versus estimated costs to date) and ascertain whether it is progressing better or worse than you had expected during planning. You can then tweak accordingly – perhaps reallocating some resources or pushing back a deadline – in order to ease any pressures that have developed on team members or the work as a whole.

Plan for completion

The way in which you complete a project is just as important as the way you start it. Closing a project down has an impact on the team, the stakeholders and any customers who are involved, so it is important for this part to be made as smooth as possible. A completion point has to be clearly defined so that everyone is aware of it – whether it’s the point at which the team are no longer required or the point at which a product or service is fully integrated into the business depends on the project. This milestone may change, so everyone involved should be aware of that change and how it will impact the project’s completion in terms of extended resources.

You should also convey to other departments when resources and team members are free to work on other projects, and send a round-up evaluation of the project to stakeholders to celebrate its (and your) success and ensure they remain engaged with it.
These project planning pointers may be obvious to some, but many projects have been derailed because simple planning strategies haven’t been followed. Ensuring that you understand the project, the skills you need to plan effectively and the need for reviewing and proper completion will go a long way towards ensuring the project’s success.

Done and the Human Condition – Can you Handle the Truth?

Written by Paul Antelman on . Posted in Articles. 7 Comments on Done and the Human Condition – Can you Handle the Truth?

Truth is not the same as “fact.” Truth is an intellectual construct only grasped and pursued by humans on this planet.

Truth is a belief system that is sometimes passed off as a conclusion that is factual and logical from verified premises. It is only the subjective sense of truth, what you believe, that will “set you free.”

I start with this philosophical premise because I think it’s critical in explaining how I have come to embrace the Scrum approach to Agile product development. As a seasoned (read “battle weary”) project manager, I needed to absorb and understand that converting entire development, nay corporate, environments to the Agile way was not simply invoking another silver bullet to rescue them from sub-performing IT systems. As one who has participated heavily in my employer’s course to prepare project managers for their PMP certification, I also appreciate and stay sharp on the foundational principles of running a good project. I have looked at the project management “triangle” as a self-evident truth of most any endeavor that companies launch.

Related Article: From the Sponsor’s Desk: A Moment of Truth

Keeping costs at bay and finishing things on time are constants in the everyday work of the project manager. The ideal, as it has been presented in traditional development environments, is to have a solid road map, well-thought requirements that clearly define the prize at the end of the project. I have done my part in “educating” my clients about the triangle and, in discussing the scope lattice, elevated the importance of “what must be done to provide value.” Scope, and what affects scope, drives risk management, change management, and closure of projects and project phases. The pre-eminence of good requirements elicitation can’t be underestimated, and entire industries have thrived in supporting the business analysts’ tasks to get scope nailed. Measure twice, cut once, right?

Traditionally, project managers have looked at scope as the immutable prize that defined successful projects and truly pleased the client. It works on the premise that the business knows its pain and clearly articulates its treatment of that pain. Projects are chartered that set objectives achievable in a month, 6 months, a year, 5 years, and even more. We do our best to manage costs and stay on schedule, but when we discover that achieving scope will take more, or take longer, we, as project managers, reach into our trusty tool kit of escalation and change control to keep everything on track. I have stayed in this lane for over a decade, shaking my head at those who would speed around me or, worse, get off the highway completely to find the ever elusive shortcut. I can see more clearly now. My treatment of scope has ignored the immutable truth about the human desire for closure, for a sense of finishing what was started. And Agile, specifically Scrum Agile, has shined the light.

Agile turns scope on its head. This is the truth that set me free because I’ve been a disciple (slave?) of scope since my early days in project management. I always go beyond software to defend scope, because I accept the premise that businesses don’t ever totally understand what they want from software. I say, “what about building a house?” If the owner’s top priority is the features of a second-floor bedroom, how would we do that first? How would we apply the notion of incremental and potentially releasable product to a house? So, in my old persona of defender of scope, I shout, “know your business requirements, know what you need, write it down, and test the requirements, the “what must be done to add value””and you might find that you don’t need new software at all. But define that scope and hold it like it’s a precious possession.

Adopting principles as truth goes beyond assembling logically progressive facts into an evidence-based conclusion. You need to believe in the principles and make their truths self-fulfilling prophecies. And this is not a negative imperative because part of the human condition is to make things work in the face of constraints and apparent imperfections. I’ll go beyond that and suggest that getting things done is the most central tenet of the organizational human condition. And guess what? The central tenet of Scrum Agile is getting stuff done.

So the fundamentals of Agile, and we’ll focus on Scrum here, are about getting stuff done. There is nothing more satisfying in the human experience than completing something. Stuff in progress is maddening. The more “in progress”, the less satisfying the human experience. We all say “life is a journey” and philosophers prod us to focus on being happy with “in progress” but our minds contort those journeys, we look for milestones, we look for signs that something is complete. It might be part of a larger thing, but some chunk is complete. This is why the long distance runner wants to know about his splits, why we have “legs” of a journey, why those who simply don’t care about or perceive their progress are likely high or mentally ill. I’m not being flippant here. I think this is true, and I think it is a core truth.

Just as true is the notion that we’re never done with everything that should be done. We’re all Sisyphus, pushing the rock up the next hill, only to watch it roll down. There is no such thing as “done” for a business. It can meet needs, make a profit, and give people a living, but if it doesn’t increase its profit, meet more or unmet, or invented, needs, then it is deemed “unsuccessful.” And this is why we need to be suspicious of scope.

There’s another hill on the horizon. Another set of realities. Are you coming around to accepting truth as more about cosmic beliefs than worldly facts? Agile has. Scrum has, in an elegantly succinct way. That being said, truth is always hard. Scrum is simple to understand and difficult to master (Schwaber and Sutherland, p.3). Difficult? Yeah, like running a two- hour marathon is difficult.

So Scrum is also based on the notion of done. The Definition of Done, as set by the product owner, is the contract of the Scrum Agile “project” outcomes. .If there is merit in my claim that we yearn for a sense of doneness in a world where nothing is ever completely “done,” then Scrum Agile is my highway. But this journey is going to be rocky, believe me. Be humble and realistic in your notion of done. If you take this fork in the road, you won’t produce an inferior product as opposed to the grand rollout of traditional SDLC-produced software. But there will be a learning curve and some painful revelations. It might seem like you’d be better off doing it the old way. Don’t be fooled; don’t listen to those “enjoy the journey” charlatans.

Working toward a progressively elaborated definition of done is a marvelous thing, only appreciated fully in retrospect. Measure what you have and consider how quickly you started making it. The painful phases of “forming” and “storming” have to occur before we get our footing on this tough road.

Scrum is presented as a pure framework; it doesn’t compromise on its core principles. All the constraints that make it less than successful can be addressed by making organizational changes, by transforming the corporate truth proposition. We all know, we all sense, that this is very hard. The real challenge is to convince those who control the purse and see product development goals only on calendars that the truth is about change, and that taking this on means reuniting the seemingly incongruous forces of change with our yearning to get things done. Done, in the new reality, is a to-be-continued construct. Scrum is hard, and tiring, and frustrating in a genuinely Sisyphean way. Hell, I’m not even an Existentialist, and I can’t ignore that rock ascending, only to roll down again.

But it doesn’t mean that we shouldn’t try. It certainly doesn’t mean that we shouldn’t believe in the truth about our quest for done. Colonel Jessep’s quote in a Few Good Men, that “you can’t handle the truth” might be a fact. But you don’t have to “believe” in that and walk away. And if you won’t even try to find the truth, then the truth will never set you free.

References
1. The Scrum Guide™, The Definitive Guide to Scrum: The Rules of the Game, Jeff Sutherland and Ken Schwaber, July 2013. www.Scrum.org
2. “Maximizing Value with Scrum / Agile” two-part course, developed and delivered by Maclore Christensen, CSM, CSPO, November 2014.
3. Camus, Albert The Myth of Sisyphus and Other Essays, New York: Alfred A. Knopf, 1955

Why Social Software Makes Sense for Project Management

Written by Mark Broadbent on . Posted in Articles. 4 Comments on Why Social Software Makes Sense for Project Management

A project is a human endeavour – a temporary society of people with a common interest and a desire to achieve something.

Project management as a discipline attempts to put some repeatable practices around achieving these things. It is forethought about forethought.

The problem is that we project people often get caught up in the process and the artifacts of those processes that we forget to keep our eye on the end-game – the delivery of something for our organizations.

A lot of project management software (certainly in the past) has tried to put some way of supporting a particular process and then sharing the process artifacts with the team in the belief that if we all just see the process artifacts, the project will work. But the big issue is that this way of working still does not guarantee the right result.

Why?

The problem is that I believe our tools often fail in understanding 3 simple principles of human endeavour, especially as they relate to projects:

  1. There is an almost infinite way to achieve something;
  2. Nothing in human endeavour can be totally predictable;
  3. Most often, the big issues that confront most projects are people-related.

To date, we have tried to reign in all of this messy human stuff by following a process – effectively trying to deny the indeterminate nature of most human endeavours – particularly in the creation of something new.

Ironically, it is this indetermination that is our strength.

Through variation and changing influences we humans produce breakthrough results, especially when we need to be creative to overcome issues.

I cannot recall any time when a truly breakthrough change, an “ah-ha” moment, a new product, a creative solution to that seemingly impossible problem, came from having only a disciplined processes. (I’m happy to be proven wrong). There are plenty of examples of competent results being achieved using “the process”, but the new, inventive, brilliant?

I believe that it is simply counter-intuitive to try and achieve a different result using the same process as we did before. It’s certainly hard to achieve something we did last time when the influencing factors change and they nearly always change as time progresses or the environment or people change. It seems that we believe that if we just keep one thing constant – the process – that we will overcome these other variables. The changing environment, changing people and changing influences adds to the indeterminate nature of human endeavours – especially in an ever increasingly complex world.

We humans are essentially adaptive creatures – we take our changing circumstances and influences into account, learn from them (hopefully), and as a consequence, change the way we do things to get the result. However; our processes are often designed to try and ignore this very fundamental nature.

If we work together, draw on each other’s unique perspectives and knowledge we handle indetermination better. The collective mind becomes greater than individual perspectives.

In the process, we move away from thinking of work as a set of transactions or an assembly line of activity that just has to be completed to the process, to thinking and working interactively. When we do this, we achieve something else, something better.
A high level of interaction between team members within a project provides a context for sharing thoughts, ideas, status, issues, events, etc.

This is the secret of social-based software as a tool for projects. Social based software allows for the indetermination of each unique project as a piece of human endeavour to meet the challenges thrown at it by using natural human interaction. This results in a way to achieve our result exploiting the three principles, instead of fighting them.

This process develops a collective consciousness and a shared result with high buy-in. It allows us to handle the unpredictable. It allows us to achieve something in a way that is humanistic, using a variety of approaches.

It does not mean that we have to abandon the good things that our old disciplines provide. It adds a dimension – the dimension that supports the indeterminate nature and the humanness of project endeavours.

Social software in projects is not a panacea to failed projects – but at least it provides an opportunity for success in a way that our favourite project management methods may not – something that supports the indeterminate human aspects of real life projects – people.

And you know – it could just make “work” fun. Because essentially we like to interact, be part of something bigger than ourselves and to be inventive.

Social based software provides us with this opportunity.

Project Management is a lot Like Baking

Written by Kiron Bondale on . Posted in Articles. 3 Comments on Project Management is a lot Like Baking

I love to bake.

Nothing puts a smile on my face faster than the smell of a fresh batch of goodies or the instant, positive feedback I receive from family and friends when they sample the outcomes.

So let’s discover what project management lessons might be learned by stepping into the kitchen.

Related Article: Project Management is All About Trust

Quality in, quality out

You can clearly taste the difference when you bake with higher quality ingredients. Yes, you could bake a cake with cheaper inputs but isn’t the effort you are putting into the exercise worth the greater investment? Arguably, the extra amount spent will provide a taste which far exceeds the incremental costs.

The same holds true when staffing our projects. We shouldn’t settle for lower performers just because they have the capacity. As I’ve written previously, we need our team members to bring capacity, commitment, AND capability – all three attributes are required for project success.

You need to be strategic about resourcing. It sounds great to get a team of all Grade A performers, but a short-lived team of “all stars” is likely to be too costly, unavailable, or would generate more headaches due to ego clashes than the incremental value they would provide.

As with baking, you should identify the one or two key ingredients which will result in a substantial uplift and focus your efforts on securing those.

When baking a chocolate cake, I don’t worry about getting the best quality flour, eggs or butter. But I will favour Dutch cocoa over regular, and real vanilla extract over the cheaper artificial variety. The result of using those is evident with every bite!

Context counts

One size does not fit all when baking. The cake which turns out great when our oven is set at 400 degrees for 50 minutes might still be uncooked when we try the recipe at a friend’s place. Doubling the size of a recipe doesn’t mean you can get away with doubling the baking time – you might end up with charcoal. And finally, the quantities you use of specific ingredients might not scale linearly.

The same holds true with project management.

The complexity of a project does not scale linearly. The reason that Fibonacci sequences are well suited for relative size estimation as the effort involved to complete a work item at higher levels of uncertainty could be exponentially greater than for simple work items.

Practices also need to be tailored to the specific context of a project, the culture of the team, and the delivery maturity of the organization and stakeholder ecosystem. Applying rigorous practices which worked well on a large, complex project to a much smaller initiative is a needless waste and trying to manage a large project with the practices which worked well at lower levels of complexity is professional negligence.

Companies should embrace frameworks, not methodologies. When implemented well, the former provide sufficient guidance to ensure that the right process tailoring decisions get made whereas deploying the more prescriptive latter can often result in the Goldilocks tale of either too big or too small for most of the projects in the portfolio.

Follow recipes until you are safely able to experiment

When I bake something for the first time, I will follow the instructions exactly in terms of ingredients and process steps. But over time, as I get more familiar with it, I can safely begin to experiment by trying different ingredients or approaches. I know that I can get away with reducing the quantity of sugar in my cake recipes or substituting a different liquor when making Amaretto cookies, but that confidence comes with experience.

When we first start to manage projects, it should be the same way. With the support of a seasoned project manager and sufficient process guidance, we should be able to manage a small, low complexity project successfully. On our second project, we will replicate those behaviors and practices which helped us on the first project. Over time, our competency with multiple hard and soft tools will improve so that we can pick the right approach for the specific context of a situation.

But this competency will only come through progressive increases in project size or complexity. Taking a project manager who has been successful managing small maintenance projects and handing them a highly complicated system replacement program would be as foolhardy as asking an amateur baker like me to bake a multi-layer wedding cake under time and cost constraints.

As Tom Douglas put it “If you don’t have the confidence in baking, commit to making the recipe three times. The first two, do it exactly the way I’ve told you to make it. Twice. The first time you’ll screw it up. The second time it will come out pretty good, and then the third time, make your adjustments.”

When we bake, we hope that the outcome will be tastier than just the sum of the ingredients – in that, it is exactly like managing projects.

OUTSIDE THE BOX Forum

Written by Robert Wysocki on . Posted in Articles. 2 Comments on OUTSIDE THE BOX Forum

In 2010 the CEO Office at IBM published the results of a survey (IBM, 2010, Capitalizing on Complexity: Insights from the Global Chief Executive Officer Study, GBE03297-USEN-00, Somers, NY) they had conducted of 1541 CEOs from 60 countries.

Their major finding was that over 50% of the CEOs admitted that they were aware of the complex and uncertain environment in which they were forced to do business, but they were not prepared to deal with it, and they didn’t know what to do about it. They also expected complexity and uncertainty to continue to increase.

If that isn’t a clarion call to action from the project management community, I don’t know what is. To a large extent that call has been ignored until today. Join me and we can change that.

outsidethebox

OUTSIDE THE BOX Forum is my disruptive attempt to suggest how the project management community might address the global problem reported by IBM. I’m going to get your creative juices flowing by offering artifacts that have been used successfully in my ECPM Framework. Some of these artifacts are all situation and client-based, and many evolved over time. They are adaptive. They can be disruptive of common practices. But I have found situations where they have been successful too! We just need a strategy for using the right approach tailored to the right situation. I recognize the challenges we face and that the solutions are not always obvious. Many will continue to be elusive never be found unless we take that first step outside the box. This forum will be successful if you participate with me. I want to hear from you and your experiences stepping outside the box! Learning opportunities will arise, they are it is just another step on our journey to discovering those elusive solutions and responding to IBM’s call to action.

If you factor in the high failure rate of IT projects as reported by the Standish Group you should see the gravity of this global situation. But the response from our PM community has not happened. If you consider yourself to be a professional, you should have taken up the challenge to make a difference. This column is another chance to redeem yourself. It is my clarion call to you. The time has come for you to step up to the bar and do something!

My plan is to stoke the fires with a new posting once a month. Many of them will be derivatives from the IBM CEO Report. I have long been a proponent of outside the box thinking to solve project management process and practice problems. I will be sharing those with you with the expectations that you will respond in kind. Let’s take a brainstorming approach and find the much-needed process and practice solutions.

I won’t minimize the risks especially as we start our journey into the unknown unknowns. It is critical that you participate. I want to hear your thoughts about how we might direct this journey. And I promise an immediate response.

OUTSIDE THE BOX FORUM is a bold venture into the unknown. I expect to share a variety of disruptive ideas for your consideration. These ideas will address a number of open questions, issues, and challenges to complex project management. This effort will not succeed unless you participate with us. Help us out with your response to a most important question: