≡ Menu

Book review: Project Workflow Management

Summer of books 2014“Project management is indeed a very exciting and rewarding profession, but at the same time, it is one of the most difficult jobs, often misunderstood by project team members and management alike,” write Dan Epstein and Rich Maltzman in their book, Project Workflow Management: A Business Process Approach. I agree; it can be a challenge to get anything done as a project manager, and Epstein and Maltzman explain why:

“The project manager will never win a popularity contest, because even though he or she is not usually a personnel manager of team members, he or she nevertheless sets work deadlines, demanding status reporting and requests adherence to the project work rules and schedules. These demands – coming from someone who is not technically their supervisor – won’t necessarily win you any favours with team contributors.”

The concept behind this book is that it is a full project management workflow, covering the whole project lifecycle. The authors define ‘workflow’ as ‘a means to identify and diagram procedural steps and logic used to achieve a specific goal.’ They say that this step-by-step sequence is different from the process models in A Guide to the Project Management Body of Knowledge (PMBOK® Guide) and other project standards because it gives you the detail of how to do each step. That’s why the book is so chunky.

Running a project with the workflow

Project Management WorkflowYou can use the book to execute projects with very little formal project management training, but I think you’d find it easier to put the concepts here into practice with some understanding of projects. It’s very detailed and there are numerous tables, templates and diagrams. It would help to have access to the flow diagrams while reading the process descriptions and steps, and that’s hard to do on an iPad. You could print out the diagrams and have them with you if you wanted to get this book on an e-reader.

The explanations are comprehensive and there are worked examples where necessary to help you. For instance, there’s a step-by-step worked example of cost benefit analysis. Getting into this steps you out of the process so it’s a bit of a diversion from the flow of that section but the idea behind it is to ensure that you know how to do each step.

Useful pointers for project processes

The book includes a whole chapter on estimating and has a useful checklist for requirements. There’s a good section on earned value and another good chunk about training. Another thing I particularly liked is that the authors recognise that you don’t just work on projects during a normal day in the office – and even if you do, the chances are that poor planning makes you ineffective some of the time. They write:

“Delivery team members spend around 20% of their time on phone conversations…ad hoc meetings, conversations, coffee breaks etc…The efficiency of resource utilisation depends on the project manager’s planning skills. A skilled PM may reach 90% resource utilisation at best. In other words, 10% or more of resource time is often not productive due to inefficiencies in resource utilisation.”

They also recognise ‘project management time’ as an overhead. In other words, you have to ‘do’ the project management and this takes, they say, between 10% and 20% of the total project effort, so make sure you are adding that on to your task estimates.

A downside of this book is that I found it very technical and difficult to read in parts. There are also lots of acronyms, and if you miss the explanation not all of them are obvious, so you have to go back and check earlier in the text to find out what they mean.

Should you share your plans?

The authors advise project managers not to share their project schedule with the client “to avoid clients’ attempts to micromanage the project or request reporting the completion of every scheduled task.” They go on to write:

“If you admit them into this level of project detail, they may interfere with the project management processes, even asking to remove some quality or risk related tasks in order to save their costs. The second reason is that you cannot show the client some of the project tasks, like internal project reviews and meetings or tasks related to the containment of some negative elements related to the client in the project risk assessment. If the client is aware of those meetings, you cannot stop them from sending their representative.”

I don’t agree with this advice. I don’t think there is any reason not to share the plan with the project customer. If they don’t have the maturity and project management knowledge to know what the tasks are, then it’s your job to explain it. Of course there are discussions you have with your team that you wouldn’t have in front of them (mostly about how awkward they are being changing the requirements or how they are keen to push blame for delays on you when it’s really them causing the hold up). But you can have these discussions outside of the formal risk meetings. And surely if you are having these discussions about them it’s best to find a way to discuss it with them as well.

Overall, Project Management Workflow is a new approach to project execution. The supporting diagrams and tables make it possible for you to adopt this approach on your projects, and it would also be useful at a corporate level, especially for companies looking to formalise project management processes and methods within their teams. It is a comprehensive resource that walks you through the processes with detailed flow diagrams and clear guidance for making your projects a success – although like all project management processes and approaches, you can ultimately decide for yourself which bits to follow to the letter and which to adapt for yourself.

Buy on Amazon.co.uk
Buy on Amazon.com

1 comment

Can you really manage with just 5 milestones?

Ninja book cover“A perfect project plan for regular, light-touch steering should contain no more than five milestones,” writes Graham Allcott in his book, How To Be A Productivity Ninja. “Too often, milestones become micro-management or seem to provide complication and confusion rather than clarity. So in each of your projects, you should look for between one and five milestones. Never more than five, never fewer than one.”

Do you agree? I don’t. But let’s put that aside for a moment and look at what he suggests those 5 milestones should be. “The five-milestone model of projects is all you ever really need,” he continues, going on to set out what those milestones should represent. They are:

Establishment: marking the fact that the project is now set up with a team in place.

Underway: checking the progress of the first few days to ensure that things have started in the direction that you expect and find acceptable.

Mid-way: checking progress at the half-way point to ensure you are still on track to achieve the objectives and that those objectives are still relevant.

Completion: marking the fact that the project is now complete, drawing on success criteria that you set at the beginning.

Celebration: a milestone to celebrate success, review learning points and say thank you to those involved.

On small projects this model will probably work quite well. I can see it being used in projects where the team is only a couple of people and the work will be done in a few months or sooner. But on anything that lasts over 6 months, has a sizeable budget or a team of more than 10, this model is inadequate. You would never be able to track progress or report effectively with so few milestones in your project plan.

How many milestones make a plan?

To be fair to Allcott, he does briefly mention the possibility that “there will be complicated projects with hundreds of inter-dependencies, where you need to find the ‘critical path’ through all of the detail and complication.” In those situations he recommends hiring an experienced project manager, someone, I assume, who can do all that for you. However, “old-style project management [whatever that is] rarely works well for day-to-day projects.” He doesn’t define a day-to-day project but he does talk about creating new brochures and websites so that’s the kind of thing I think he means. As a bit of a fan of ‘old-style project management’ I think it would work well for all kinds of projects, provided that you scale it appropriately, and that doesn’t mean cutting out all the milestones on your project plan so you are only left with 5.

So, what’s the smallest amount of milestones that you would have on a plan, or is the answer really ‘it depends’? Let me know in the comments below!

8 comments

Social Media for Project Managers: Q&A

I gave a presentation on social media for project managers at the PMI Learning, Education and Development Community of Practice at the end of last year. They run a successful online book club and they were discussing my book on the subject, so it was great to be asked to go along and round out some of the ideas.

There were about 350 people on the webinar and we didn’t have the chance to go through all the questions that were raised, so I thought I’d address some of them here. Let’s crack on…

Our company is pretty concerned about using social media due to the security implications. Thoughts on that? (Angela)

This was raised by a number of people and there were several comments along the lines of ‘my company won’t let me use social media tools at work’. This could be because of non-disclosure agreements (mentioned by someone) or other concerns about privacy. However, my view is that if employees are going to use Facebook or Twitter, they’ll do so whether the company lets them or not – these days most people have a smartphone with internet access, so unless you check your phones at the door you can access these tools when you go to get a coffee. It is far better for a company to monitor and control access through policies and education than let employees do and say whatever they want on social media sites.

When it comes to using social media tools for project work, you can address the security concerns and manage appropriately. For example:

  • Using tools that you can host in-house behind your firewall so they are not available to external audiences e.g. Yammer, wikis
  • Using tools that enable you to export your data when you need to or when the project is over.
  • Using tools that do not host data overseas when this is in breach of your local regulations or contracts.

The short answer to addressing security concerns is that if you can’t address them adequately, don’t use social media tools. You can manage a project perfectly well without instant messaging or a wiki; people have been doing that for years. So for all I’m an advocate of social collaboration tools, don’t use them when it doesn’t make any sense or puts you in breach of agreements or policies.

How do you define Organisational Instant Messaging? (Daniel)

Tools like Skype, Microsoft Office Communicator, Spark, Cisco Jabber and Lync are all examples of organisational video conferencing. Some of these are available free, some as part of other software. My recommendation is that you try out a couple (of free ones) and see what sort of features you use regularly. Then if you want to invest in a paid-for solution you know what you are looking for.

Younger employees are more comfortable with social media tools. (Iain)

Actually, I don’t agree. I don’t think technical literacy (which is what I call the ability to use these tools, and any other bits of tech) is defined by age. There’s a growing group of ‘silver surfers’ who are just as adept at using them as some young people. And I know people younger than me who have chosen not to be on Facebook or to use social media products for various reasons so don’t have a clue how to do it.

Having said that, I can’t cite any research at the moment that backs up my anecdotal opinion. What I would say is that don’t let the age of your team members lead you to make unfair assumptions about their ability to adopt new ways of working or manage with new tools.

How do you manage the information overload? (Various people asked this)

This came up as we were talking about instant messaging and making sure that you can cope with the archive trail that it produces by being able to manage that sort of information and file it somehow.

Too many communication tools can result in more interruptions and therefore more distractions, so you need to think about how to manage the various streams of information that social media tools open up to you in order to avoid information overload. Generally, I would say that you should trust your team enough to not need to monitor all the communication or to push all the communication through yourself, or you will drown in the data and slow the project down.

When it comes to instant messaging, you can store the output from chats. Your IM tool may have settings that sends the chat to you as an email after the session ends, so check if this is turned on and use it if it is available. These can then become project documents and can be stored and archived in the same way as meeting minutes.

Henrik also raised a good point: since e-mail (almost) can’t be avoided, multiple ways of communicating by also using other social media tools may result in multiple paths i.e. dilution and confusion in the project. Kumar pointed out that email can also do that, especially if you take people off the circulation list (or add them on halfway through the discussion).

It isn’t always easy to get the balance right but it’s good practice to ensure that your messages are always consistent. Sometimes people do need to hear the same thing several times before they believe it so using several channels to repeat the same (consistent) message is appropriate. Of course, if you say different things through different channels, expect total confusion!

0 comments
angel

Angel Berniz

Angel Berniz, Director of ProjectManagers.org, is speaking at Nordic Project Zone later this month. He’s talking about ISO 21500, the new project management standard. I caught up with him to find out why this new standard is important and how it will impact project managers.

Angel, tell me why the new ISO 21500 standard is important for project management?

The ISO 21500 is the recognition of a profession that has been developed within the last four decades. It concentrates, into nearly 40 pages, all the knowledge that can be accepted as standard on project management.

It is been accurately developed by the international community with volunteers from more than 40 countries, with no commercial intention. ISO 21500 is the umbrella over all the rest of the project management bodies of knowledge and methods. It is important because in a globalized world, where anyone can be asked to lead a project in any location, one needs to apply the worldwide accepted International Standard project management framework.

Did you find anything surprising in the standard?

I strongly believe that ISO 21500 will forever change project management. Angel Berniz

Yes, there were some new points. The most important one was the incorporation of Stakeholder Management. Later, PMI’s A Guide To The Project Management Body of Knowledge (PMBOK®) – 5th edition added this as well.  At ProjectManagers.org, we celebrated this renewed focus towards people, because this is a value we also share (we are not a project management community; we are a project managers community).

Where do you see individual standards like PMBOK® going now? Do you think they will all be brought in line?

Project management is evolving to become more Agile. PMI has done it, with a new Agile Certification scheme. The problem is that now PMI has two worlds: the waterfall PMBOK® framework and the Agile Methodologies. Of course, PMI was influential in the ISO 21500 implementation and they coordinated the dates between the ISO 21500 implementation and the PMBOK® 5th edition. I am sure they will always be brought in line.

How will it impact project managers?

I think there are still companies nowadays that don’t apply formal project management. They only manage initiatives and execute various tasks. Others only apply project management for big projects, but not for projects of a month’s duration. Others apply some kind of project management methodologies, but they are not international standards and depending on the country where they need to deliver their project they could be asked to manage their project using other frameworks. No matter what approach a company uses, the new ISO 21500 will be the solution.

I strongly believe that ISO 21500 will forever change project management. It can be applied very easily by any kind of business (from small to big companies).

There is something amazing about this new ISO 21500. It defines the Processes, Inputs and Outputs but not the Tools and Techniques. And this is just where Agile fits in. We can use Agile ISO 21500, without needing to choose between waterfall and agile anymore. So, using this approach, ISO 21500 can have wider applications than PMBOK®. Of course, if one wants to apply only a traditional waterfall approach, ISO 21500 can be complemented with some of PMBOK® Tools and Techniques. But the real power will be adding Agile to ISO 21500.

If a project manager wants to adopt the new standard, how easy will this be?

Nordic Project ZoneAdopting ISO 21500 is very easy, in fact the guidelines are about 40 pages. So there are no excuses for not reading and trying to apply it. Beginners will find it an easy way to implement project management. PMI practitioners will find the outline reference necessary for guiding their projects.

OK, so what’s your advice for putting it into practice?

My advice for applying it is to look at your project stages and the required project management deliverables that are required in each phase. That is, don’t blind yourself by having as reference the subject groups (PMBOK’s knowledge areas), but focus on progressing your project in its lifecycle and be aware that in each of the steps (processes along the workflow) you have all the required outputs from the subject group.

I expect this has been a hot topic for the ProjectManagers.org community. Can you tell us more about it?

ProjectManagers.org was set up to fill the need of having a community of trusted and reputed professionals sharing their knowledge with the project management community. The concept is a PLC (Professional Learning Community). The difference with other organizations is that ProjectManagers.org is only about people. This is not a company nor a business and I set it up because I saw that other organizations are always focused around local chapter interactions. My purpose was to share and interact globally. We collaborate on a voluntary basis to develop the project manager’s profession with a method of direct knowledge transmission from professionals to professionals.

Who can get involved?

Everyone is invited to participate and collaborate in the community. We write about everyday project management situations, lessons learned, tips, advice, concepts, frameworks and best practices, software tools, etc. Our readers are worldwide, but there is a high concentration in the United States. And I must say that I am meeting very interesting people and it’s an amazing experience that opens your mind. I hope to see you soon.

Thanks, Angel!

Nordic Project Zone is being held in Copenhagen between 25 and 27 November. Find out more on their website here.

4 comments

How men and women manage risk differently

Angela Minzoni

Angela Minzoni Alessio

Earlier this month International Project Management Day took as one of its themes the role of women in project management. I spoke to Angela Minzoni Alessio, PhD, an industrial and business anthropologist from the Ecole Centrale in Paris, about how men and women approach project risk differently.

Angela, you’ve spent a lot of time researching the differences between men and women studying and working in project management and risk management. What is the main difference between the way male and female academics and practitioners approach project management research?

The overwhelming majority of authors about risk and project management in academia and firms are men irrigating the field with expressions like framework, plan, control, master… It has become so usual that we have lost awareness about the male-gendered way of thinking conveyed through this vocabulary. For example, amongst male researchers in project management subjects we find: concept mapping, quantitative representations, automatisation, competition and decision making while women’s scientific (or corporate) articles will favour subjects like training, ethics, networking, intuitive use, and participative innovation.

How does that impact the study of risk management?

This mainly male scientific knowledge production makes little reference to the human part of the risk equation illustrating thus the narrow focus that is a hallmark of much current risk management practice.

OK, so risk management practices are inherently linear, as a result of the fact that it is mainly men who have researched them, if I can simplify and summarise your years of research! How do women and men approach risk management differently?

In fact, the difference starts upstream to risk management itself, by an integrated way to look at management and strategy at the same time. For women, risk management is much more a collective challenge than an individual one, with the aim of creating a stakeholder’s sustainable policy rather than developing a new step for personal power.

A non-risk example is the one of female orchestra conductor, Xian Zhang. Let’s look at her movements and expression: everything tends towards the listening and the harmonization of the players. No heroic, jerky, staccato, almost frenetic movements as do show the great majority of male orchestra conductors.

Xian Zhang

Xian Zhang and soloist Karen Gomyo. Photo credit: heartonastick on Flickr (http://www.flickr.com/photos/heartonastick/82780747/)

If we transpose this attitude to risk management, we observe women will tend to be less impulsive and more willing to listen and explicitly acknowledge feelings such as danger and fear. This same attitude is also favourable to the disclosing of errors, an essential step in risk management. Nevertheless, because of the gendered social context into which risk is embedded, you can find women adopting male standards.

It’s worth mentioning intangible risk management and as an example, strategic and competitive intelligence. In this field, men tend to reproduce traditional military/aggressive-defensive masculine patterns whereas women seem to design specific approaches to intangible risks based on dynamic coordination, sourcing and networking.

But men can do the type of risk management you say is particularly female – considering that human element and working collaboratively, can’t they?

Yes. I think it is still exceptional to observe male managers having opted for more sensitive and insightful risk management approaches than the standard and traditional one’s made of generality, control, power, attacks, and bravery.

Why do you think there are these distinct patterns in how men and women manage project risk?

Through the generations and quite independently from national cultures women have been trained (even if not explicitly) to be responsible for caring for life – their own life as care givers as well as for the life of their children. It is more than a coincidence, for example, that women enjoying risky sports are rare. Women have traditionally been put into situations for caring about different things at the same time: childcare, housekeeping (including budget management), professional work, caring for relatives etc. This has taught them to have an acute pragmatic sense and to develop spontaneous mechanisms of getting and crossing multiple information sources. These contexts have also enhanced women’s multidimensional listening capacities.

Risk is still a field where men, through working relationships, reaffirm their own perception and that of their peers, the traditional male values: brave danger, be a hero, don’t be impressed, give orders, be under pressure, don’t cry or show feelings, stay extra hours at work and be very happy and proud of it, etc. Risk situations present the opportunity for men to operate this unspoken process of self reinsurance.

OK, so what’s the impact of all this for project managers?

It could be threefold:

  1. the evolution and taking into account qualitative policies and evaluation instead of only or predominantly quantitative policies. In other words, being open to risk management from a wider perspective.
  2. the focus on end-to-end prevention and care systems from design to implementation and evaluation. We should be looking at risk management from start to finish.
  3. an increasing capacity and focus on training to explicitly deal with subjects like morale, taboo, anger, hope or fear. Project management training should include all these when it comes to dealing with risk.

Today’s mainly masculine way to deal with risk and danger remains attached to objectivity and purity, with the risk analysis profession favouring the paradigm of rational choices, thinking probabilistically and using universalising terminology.

So we all need to be more open to different perspectives on managing risk. Thanks, Angela!

Angela Minzoni Alessio, PhD, is an industrial and business anthropologist, prospectivist, multi cultural consultant and part-time Professor at Ecole Centrale Paris. Her working experience includes Latin America, USA, the Near East, Central Asia and Europe. She is mainly involved in cultural impacts on training, decision-making, risk mitigation, governance, innovation and gender issues.

 

4 comments

Gamification in project management

Connect 4

Last year, it was all about social media. This year’s hot new trend is gamification. What’s that, I hear you ask? It’s such a new word that my spellchecker flags it up as an error.

Gamification has been around for a while. It’s the art of making work seem less like, well, work. It’s about using techniques used in games in non-gaming contexts in order to increase engagement. Back in 1999 when I worked for American Express, we had a company-wide game. For every shop you reported that did not accept the Amex card, you received a game card with a picture on. It was a bit like Snap. If you matched the pictures on the cards you could cash them in for a prize. I remember collecting dozens of cards and being disappointed when they didn’t match and elated when they did. I must have got a few prizes that summer but I can’t even remember what they were. It’s playing the game that I remember, not the outcome.

APM have even set up a gamification in project management group this year. The Gamification Study Tour is funding a group of new project managers in the Thames Valley region to investigate innovative methods for improving engagement amongst project stakeholders through gamification.

So how does it work?

Gamification in practice

People like recognition, and they like to feel part of something. Gamification techniques tap into that – the idea of leaderboards, badges and levels. Games often include things to collect (like houses in Monopoly) or privileges if you hold a certain card (like The Really Nasty Horse Racing Game), or a way of collecting points (like Scrabble).

Putting these social triggers into the workplace is supposed to make people feel more engaged. We see it through:

  • Badges, awards and shields (like on projectmanagement.com)
  • Leaderboards (like the LinkedIn groups ‘top influencers this week’ feature)
  • Points (like RedCritter Tracker, an agile project management software tool)

The APM group identified 5 benefits to like this. They are:

  • Increasing productivity, as people stay at their tasks for longer because they are more fun
  • Improving morale, as people like social recognition, collecting ‘likes’ etc
  • Increasing quality, although I don’t know how this is related to gamification techniques
  • Increasing employee retention, because life at work is nicer
  • Creating an exciting work environment, because we all like to work somewhere exciting!

I’m also sure that some people would be very happy in a work environment that doesn’t encourage competition or too much excitement through leaderboards, so I think there are some people who would be very much left out of any project gamification activity. PropsToYou is a project management tool that doesn’t use leaderboards and instead encourages people towards their personal best. I think we’ll see more of this kind of use of game theory in the future as people get better at how to understand the practical aspects of motivational theory in a business environment.

Gamification for collecting data

Gamification makes sense from a business perspective as well as an employee engagement perspective. Better data leads to better decisions.

Of course, companies only build game-like features into their software or processes for a reason. Like the Amex game, it’s about collecting data. If you use gamification features on your online project management tool, you can encourage people to enter their project reports, task updates and so on. Anything that encourages people to use the product has to be a good thing, as often software implementations fail not because the software is no good but because people prefer to work outside it.

With consumer-led gaming, companies can get all sorts of data about customers. Starbucks is doing this at the moment with the 2012 Red Cup Challenge, a Facebook game that I’m sure shares your details with Starbucks behind the scenes and therefore gives them useful information on their customer base.

In short, gamification makes sense from a business perspective as well as an employee engagement perspective. Better data leads to better decisions.

The difference between gamification and behaviour shaping

In my latest book, Customer-Centric Project Management, I talk about gamification as one of the ways to address the challenge of needing to collaborate on project teams. I was lucky to have some insight from Mattias Hällström, Founder and Director of R&D at Projectplace. “One of the major reasons for Facebook’s success is the way the ‘like’ feature is implemented to encourage positive feedback,” he said. “Heavy Facebook users get addicted to positive feedback from their friends.”

Mattias explained that in behavioural science, the human reaction to positive feedback is explained as intermittent re-enforcement of behaviour by the release of dopamine, a neurotransmitter that is intimately connected to human emotion. “It is a powerful social mechanism hard-wired into the human brain,” he said. “Positive feedback creates trust and reduces defensive behaviour, and it has evolved to enable humans to rapidly align their behaviour to each other to cooperate efficiently.”

Projectplace has tapped into this by including features that help the project manager to shape team member and stakeholder behaviour. They call this ‘behaviour shaping’ instead of gamification. “That’s why we have implemented a Facebook inspired ‘like’-feature in the Projectplace Conversations tool,” Mattias explained. “With this the project manager has a well-recognised and powerful usage model to encourage desired behaviour of team members and project stakeholders. We call this ‘Collaborative Planning’. Our goal is to help people involved in a project to coordinate and align their commitments with the project purpose to become more customer-centric.”

I think we’ll see more companies adopting gamification and behaviour shaping techniques in project management, and this will evolve as people realise that there is more to successful game-style features than leaderboards and setting up project team members to compete with each other.

However, I’m not aware of any research into this in the project management field particularly. It seems as if most of the academic work has been around driving consumer behaviour, so things like getting people to buy more stuff with Facebook games, which is not workplace-related. If anyone knows of any research into gamification specifically, please let me know in the comments! Equally, if you have any experience of using the game-like features of PropsToYou, RedCritter or ProjectPlace (or another tool), let us know what you thought of them and whether this kind of thing encourages and engages you at work.

10 comments

Giveaway: Supercommunicator

Earlier this year I reviewed Supercommunicator: Explaining The Complicated So Anyone Can Understand by Frank J. Pietrucha. Now I have a copy to give away. Use the contact form to get in touch with the phrase "I'm a supercommunicator" by Wednesday 12 November 2014 and I will enter you into the draw. Normal giveaway rules… Continue Reading->

Book review: Trust in Virtual Teams

Trust matters because it helps build a resilient project team. It helps get things done. Trusted team members not only do only what is asked, but what the project needs them to do, because they know that the project manager will trust their decisions and actions.  Trust is a shortcut to better working relationships and… Continue Reading->

The Mr Tumble Approach to Project Management (The Parent Project Month 20)

I said we’d never resort to television while Jack is still under 2, it’s not good for his development, language learning, he’s too young, blah blah blah. But we’ve soon found out that the gap between the end of his nap around 4pm and tea at 5.30pm is awful. So hello, Mr Tumble. You are… Continue Reading->

Better stakeholder engagement: Interview with Oana Krogh-Nielsen

Oana Krogh-Nielsen, Head of PMO for the National Electrification Program at Banedanmark, is speaking at Nordic Project Zone next week and I was lucky enough to catch up with her to ask about the amazing projects she is working on. Here’s what she had to say. Hello Oana! Let’s get started: can you explain your… Continue Reading->

How to build your project management network

This is a guest post by Bruce Harpham. In the project management world, people come and go. In a matter of a few weeks, you can become close with your project team. In some cases, you may see more of your project team than your family on particularly demanding projects. But what happens when the… Continue Reading->

5 Steps for identifying project dependencies and constraints

Earlier this week I looked briefly at an introduction to dependencies and constraints on project and why they matter. Today I’m going to share a 5-step approach to identifying and reviewing all the dependencies and constraints on your project. If that sounds daunting, don’t worry. It’s a much faster task than you think. Now you… Continue Reading->