Forest and Trees

Project schedules, how many have you created in your career? I can honestly say that I lost track a while ago. I don’t even remember the first schedule I put together, nor the first tool I used. I can say that over the expanse of my career, the tools have improved in being able to create, maintain, and manage a schedule. I can also say there is more information available on how to create a schedule. If those things are true, that there is more information available and better tools, then why is project scheduling and control such a challenge? Why have we been surprised when a schedule we create in March is no longer accurate in October? What is it that happens to derail our schedule, especially after we took the time, energy, and effort to create a schedule that everyone agreed to and believed would work? What are the factors that impact project schedules and how can we ensure we have taken those factors into consideration? More importantly, have we taken the time to view it from the top down (the forest) and the bottom up (the trees)? Without zooming in and zooming out (trees and forest), opportunities to make necessary adjustments to keep our projects on track can easily be missed. Learning to work from a forest and trees perspective will serve us in our project management. Below are the ways in which we can ensure we are looking at both.

Start at the End

Being clear about the end of the project and what it produces is essential for building the plan on how to get there, and I don’t mean the narrow view, I mean the broad 360 view. Clients may ask for a high quality, quick delivery, and leading-edge functionality. Users may ask for an easy to use and intuitive product. The organization may ask to maintain the margin that was sold. The team members may want work-life balance and engaging work. Having a clear vision of what is created by the project, not just product it delivers, ensures a schedule is generated and created from a zoom out perspective. Will it produce a long-term client relationship or a once and done result? Will it strengthen employee retention or cause higher turn-over? Will it allow for additional business for the company or reduce its market penetration? Finding the balance or perhaps a way to create a win for all involved is the challenge at hand. Each project has the possibility to elevate or damage relationships while delivering the product sold. Creating the schedule outline using the 360 vision is defining the forest. Once created, gaining alignment allows all involved to have a stake in future adjustments due to changing circumstances. Additionally, the 360 vision provides the necessary components to the schedule outline while also providing stakeholder priorities when changes to the schedule are required.

Be Curious

Building the detail associated with the project, the bottom-up version, requires a great deal of curiosity. This is where assumptions can be made without explicitly discussing them. Hidden assumptions create instability in project schedules. Staying curious ensures there is no question that isn’t asked and answered in a factual manner. Uncovering the assumptions allows you to build contingency into the schedule based on as many unknowns as possible and yes, you may not uncover everything. The unknowns of a project are not known. Being clear about what is known versus what is not known ensures everyone has the same information. Preventing surprises is what is desired and staying curious provides the foundation to continue to ask questions even when everyone seems to know the answer. What I’ve experienced is that those who have experience can sometimes fall into the trap of knowing the outcome, planning for that outcome, and discovering they made some assumptions that were simply not true. Staying in a place of not knowing is more productive than coming from a place of knowing the answers.

Again and Again

Once the details have been added to the schedule, the impacts to the outline are reviewed and the review and update process is underway. The top-down and bottom-up are adjusted until the plan is agreed upon and, once agreed upon, a snapshot is taken. The snapshot includes assumptions, decisions, agreements on scope, and alignment on when the schedule will be revisited for revision to the snapshot. The project manager then begins the review on a week over week basis. Zooming in by adjusting tasks, reviewing resources, identifying impacts, and adjusting the details as needed. Zooming out by reviewing the assumptions made, the scope agreed to, and seeing what changes may be needed and when. Reviewing the 360 vision and the priorities of the stakeholders and coming back to those agreements regularly. When circumstances change that require an adjustment to the schedule which impacts the agreements reached, the project manager can work with everyone involved to determine the appropriate course of action. An adjustment to the schedule can be made without surprise and with alignment.

Summary

The way we do one thing is the way we do everything. What does that mean? It means how we create our project schedules may be how we do everything in our project management and in our lives. Learning to build our schedules from a 360 vision of the outcome we are creating will serve other areas of our lives. Once we’ve determined the 360 vision, we can build the detailed schedule. Reviewing and adjusting the schedule, looking at the forest and the trees, we can take a snapshot of the plan. Revisiting the plan based on the 360 vision, again and again, adjusting the schedule along the way rather than being surprised when what we planned didn’t happen the way we expected. What are you practicing today?

Read more...

Project Management: The Balancing Act

When I first got started riding the motorcycle I would just ride, purely for the joy or fun of the ride. I learned early on that to have fun I would have to decide on a destination and the timing of the ride. Knowing where I was going and when I would arrive freed me so I didn’t have to continually figure out what was coming next. That didn’t mean I always knew exactly which road I was taking next, I just knew where I was going to end up. When I took the bike to get to some specific place at a specific time I took a different approach. I knew the route I would be taking and planned it out. The amount of time I took planning either kind of trip, joy ride or making an appointment, was in direct correlation to where I was going, how far away it was, how much time I had to get there and how familiar I was with the route I was taking.

When discussing agile and waterfall the language we use can make it difficult because the words can be interpreted in black and white. To say agile is adaptive is to suggest that waterfall is not which is not the case. To say that waterfall is structured is to suggest that agile is not which is also not the case. Like our political system, project delivery frameworks, styles or methodologies exist on a continuum. Just as someone might say they believe in the republican doctrine they could mean everything from the middle of the road to the far right and the reverse is true for a democrat. If we look at project management in a similar way, agile and waterfall could be considered to be on the left and right. There are those that believe that the far right is the best and those that believe that the far left is the best. I’m a moderate. I believe that both have value and when they are practiced to the extreme neither may bring the value needed.

It is easy to make the mistake of over planning, of trying to make sure that everything has been identified, logged, noted and agreed upon. It is just as easy to make the mistake of moving forward before enough information is known or documented. The balance between too much and not enough is one of the topics when discussing the differences between agile and waterfall. I would argue that the topic of not enough or too much should be discussed as part of any project approach. Each project team has the responsibility to determine the right balance at the beginning of the project no matter what the delivery approach is going to be. Shouldn’t a project team always ask how much work should be done?

To be sure, I can over simplify. The insight into what is best for a specific project is in looking for the simplest answer. The amount of analysis and planning needed should be based on a fundamental question and must be answered by the members of the project team. The project manager is accountable for asking the question repeatedly. Is any additional planning or analysis going to help us get to our destination within the parameters set by our customer? I don’t think that is an agile or waterfall question, I think that is a project management question. The client, sponsor, project manager and the rest of team must answer this question. You will always find folks who need more detail and folks who run from more detail. The voice of balance is in the middle of the continuum. Too much? Not enough? That is the balancing act and it is part of every method of delivery.

Ride On, Manage On

Read more...

Project Management: What Could Possibly Go Wrong?

All projects have inherent risk. Planning and preparing for what could go wrong can help make a small error from becoming a big mistake. Project risk is inevitable, consistent application of fundamental processes and tools will help the smallest efforts be successful.

One day, early in my motorcycling career, I took a trip to the local parking lot for a quick practice of my riding skills. I’d gone there many times to practice so that I would gain confidence to be able to ride with skill and awareness on more difficult roads. Might seem silly to some that I would be that cautious but I’d heard enough horror stories about death and injury to understand the risks. Besides, I had a family at home that I wanted to return to safely, no matter how far down the road I went or which road I took.

The parking lot is at a local school about 1.5 miles down the road. The roads in our town are marked 25 and 35 miles an hour so speed was not a concern. It was a September day and I knew I’d be hot moving at such a slow speed. It was a good day for a short skill building trip that was extremely low risk. I’d done this trip before and I would encounter little traffic along the way, I didn’t have to meet anyone so there wasn’t a tight time frame and I didn’t have to get home for any reason.

I would compare this ride to one of those projects that is similar to another project I’ve done before. For me, that would be like taking a piece of software and enhancing it in some way, converting data from one platform to another or even integrating a package into an existing infrastructure. I’ve done those kinds of projects during my career and am familiar with the risks associated with these types of deliveries. I don’t mean to say these types of projects are always the same. These efforts are not simple operational activities. They are projects in that they deliver a new product or service. We aren’t just plugging in numbers or plugging in existing code.

When I decided to go out on the bike I did what I was taught to do. I checked the weather, I planned my route, I planned what I would do once I reached the lot (the actual destination is the lot – getting home safely is getting everything back to a starting place) and gathered the obstacles I needed to do the skill practice, I checked my bike, I checked myself and then I put on my gear. The bike check consists of making sure everything is in good working order so that you can prevent a breakdown (or an accident) while on the trip. My gear consists of boots, jeans (Kevlar would be good), jacket, gloves and helmet. Yes, I said it would be a hot September day. Yes, that much gear can be hot. Yes, the ride itself is low risk. Yes, it sounds excessive. The riding gear I selected was made for warm temperatures. The materials are light and airy while extremely durable. The fact is that my head hitting the pavement at any speed makes a really bad sound. And my ankle getting hit with something from the pavement or skin abrasions on my hands, arms, legs or any other part of me doesn’t sound like fun. I want to avoid injuries and even though I know nothing is going to go wrong because this ride is low risk, I wear the gear. So I’m ready to go.

Wouldn’t you do the same kinds of things to prepare to execute one of those easy projects, one that is very familiar to you? I think we take the basics of getting a project ready for execution for granted. We fail to recognize that every project is a risk. Every project must be set up to succeed prior to starting the building of the product or service. We can decide to cancel the ride anytime before getting on the bike. The things I was taught to do before the ride allow me to have a successful journey. When I fail to do those things, I take on a great deal more risk. What are those things that I was taught to do before a ride in project language?

Checking the weather is like checking the organizations willingness to recognize the project as important and to provide the resources to complete the effort. There are times that delaying may be a better option than moving forward. I’ve ridden in downpours and the ride definitely looses a portion of the fun factor when you’re riding through a monsoon. Planning the route is akin to determining the methodology and the deliverables that will be used. Gathering the obstacles as part of my planning is like gathering the requirements. I wanted to test specific skills and needed to have those defined before I left. Checking the bike is like making sure that you have the tools necessary to achieve the goal. That includes things such as organizational process, software tools, and other needed resources. I check myself to make sure I can do the job, basically checking to see if I’m too impaired from a physical or mental perspective to be successful. Putting on gear? I relate the gear to the project management tools needed to ensure the destination is reached safely. Just because you have an accident doesn’t mean you can’t potentially get back on the road. The gear helps you do that.

So how did the ride go? It went well. I finished my practice and felt good about what I’d done. It was time for the ride home. This is where things didn’t go according to plan. I was pulling up to a stop sign to make a right hand turn. Before coming to a stop I looked to the left to make sure it was ok to pull out. It is surprising to me how heavy a bike gets when it is leaning over while coming to a stop. It is a good thing I had my gear on. I couldn’t hold the bike up even though I used all my strength. We hit the pavement at a dead stop. I was embarrassed and laughed at myself for such a silly error, otherwise I was fine. What could possibly go wrong? You can drop a bike while coming to a stop.

Just like the ride, every project has moments when the project could “go down”. It doesn’t matter how easy it may seem or how experienced the rider. Making appropriate preparations and making sure everything is in place before executing is essential. The right project management processes and tools in place for the type of project being managed helps the project accomplish the goal. I don’t leave my house to ride without my gear and I know there are certain non-negotiable project management processes and tools that must be in place. What could go wrong? A lot of things could.


Ride On, Manage On

Read more...