Project Management Blogs

How do we achieve balance between ensuring that project information flows freely and protecting sensitive information?

Driving in a convertible to the Hoover Dam a couple of weeks ago, I reminded myself why the American South-West is one of my favourite destinations. The cool air of the winter desert, the pure blue of the sky and the breathtaking (albeit, barren) landscape meld into a dramatic image. The day before, we hiked in the Valley of Fire, where vistas are even more remarkable.

I must admit that I’m a fairly rabid agilist. Part of the rationale for that is the pain I’ve experienced in leveraging traditional PM techniques in software projects. Another influence is my experience dealing with traditional leadership and the dysfunction relating to driving projects and teams towards unrealistic goals.

What’s interesting though is a conversation I had with our Scrum Master team the other day. I asked them to act more like “traditional project managers”. To begin to—

• be more prescriptive at times with their teams; demanding high quality, excellent software, and adherence to our agile principles
• pay close attention to risks – planning, real-time surfacing and guiding team reactions
• encourage the teams to improve at an accelerated rate; to set the bar high for improvement
• become visible as leaders and spokespersons for their teams; to do a better job of socializing state & progress
• take the role of impediment resolution to the next level; mining for impediments…and dependencies, then inspiring action
• cheerlead for their teams; inspire and demand that the Product Owner does the same

What I was trying to convey to them was the ‘mindset’ of a “good Project Manager”…or at least the ones I’ve seen and collaborated with in my journey. You see, many agilists use the role of Project Manager as a bit of a verbal “punching bag”—implying that there is no need for them in an agile context. By the way, you see these same folks trivializing other roles too—functional managers, testers, and business analysts to name a few.

I can’t disagree more with these folks and that position. I think solid Project Managers can find a place in agile teams…a place that makes a HUGE difference. Yes, they might need to reframe their style and behaviors for an agile context, but please, please, please don’t throw away all of your approaches. Your teams absolutely need and will appreciate your skills, as long as you reframe appropriately without throwing out your essence!

The “Agile Way”?

An anti-pattern that often shows up in agile teams relates to managers and project managers losing their way when it comes to knowing when and where to engage their teams. Knowing how to effectively handle the fuzzy and scary notion of a “Self-Directed Team” it turns out can be quite challenging.

A common reaction is to treat the team as if walking on egg shells. If you see the team heading for a cliff, you can’t really say anything—as they’re “self-directed”. Of if you do say something, you must whisper…quietly…hoping that someone might hear you.

I once coached a team in Toronto. As is my typical practice, I gave them a quick Scrum overview, then planned and kicked off their first sprint. I stayed for a few days to ensure they were going in the right direction, and then I went home. I came back at the sprint transition just to see how things were going. In my first morning Scrum upon returning, one of the developers sort of “yelled at” their functional manager who was attending as a ‘Chicken’.

The team was stuck at a technical impasse and she said: “You better step in and tell us how to handle this, or I’m going to scream”. I was taken aback and after the stand-up I asked her what was up.

She said that ever since the sprint started that none of the functional managers were saying anything—nor providing any guidance whatsoever to their teams. And that she was sick and tired of it. She wanted help! I then asked the functional managers what was going on. They said that they were only doing what I’d told them—that the team was “self-directed” and that they were to keep quiet…being ‘Chickens’ if you will.

Ugh I thought as I smiled a wry smile to myself. Yes, I had told them that respecting self-direction is important. But that doesn’t imply that you don’t have a role and responsibility as the teams’ functional manager. You certainly don’t let them crash into a wall without yelling and warning them. You see, the managers missed the nuance of leading within agile teams, as many roles do. They mistakenly behaved as if they were marginalized and didn’t matter…when nothing could be further from the truth!

So—Which way do we go George?

It’s Situational & Skills Matter

Always remember that your agile PM role is situational. You’ll want to keep the values (Lean principles, Agile Manifesto Principles & Practices, Essence of your specific methods, Quality, and focus on Team) core in your thinking, but at the same time very much react to situations as you always have—with simply some ‘adjustments’.

As part of being situational, always remember that the teams’ skills & experience matter quite a bit in how you should react. If you have a brand spanking new team, then you probably want to provide more prescriptive guidance. If you have a master-level team, then your job is to softly guide & support them, but truly get out of their way. The Dreyfus model of skill acquisition is a good model to become familiar with to conceptualize the various team levels that you might encounter and to guide your adjustments.

Risk an Opinion

As in the above story, your teams still need leadership—leadership that provides clarity, vision, missions, and goal-setting. Leadership that is “in the game or trenches” with them. Leadership that endeavors to protect them and to shield them from major obstacles and mistakes. Leadership that is supportive and encouraging. Leadership that is in all cases, well, leading them…

In a word, you should evolve towards a more Servant-Leadership style. But you also need to share your thoughts with you team. Risk saying how you feel and what you’re concerned about, but then allow the team to take risks and chart their own paths. Risk telling the team ‘No’ if you feel they’re on a destructive path and be prepared to also tell them ‘Why’. Finally, risk ultimately becoming a part of the team and sharing their responsibilities.

Leverage your Instincts

As I’m writing this, my company iContact is making a fairly major release of our eMail Marketing software platform. We’ve been adding social capabilities for several months and are now exposing them via this release.

One of the things we struggled with was how we turn on our +70k customers. Do we do it all at once, or in a more measured way to mitigate risk and allow us to see how the new functionality ‘behaves’ under load. There were two schools of thought across the teams—release it ALL and release it incrementally. Most of the teams had an ALL perspective, as did our QA team members. However there were a few in the development organization that wanted a more controlled release and argued for that option. Initially they were considered naysayers, only reacting to FUD, but to our credit—we listened to them.

After much discussion, we opted for a controlled roll-out. While we didn’t encounter huge problems as we ramped-up, it allowed for us to better understand our usage metrics, plan for incremental use, and have time to fix a few lingering issues. In the end, it proved that our overall risk-handling instincts were the right way to go. I’m glad the few had the courage to “speak up” and that we trusted their instincts.

Ceremony & Reporting Matter

Remember that even agile teams still bear a responsibility to integrate back into the organization. They need to be transparent and communicative—and not simply in agile terms. It’s not sufficient to simply say “come review our burndown chart” or “just attend our Daily Scrum” if an executive or stakeholder asks you or the team for status.

Sure that is a mechanism or ceremony setup for this sort of communication. But what if that stakeholder doesn’t show up? Does that alleviate your communication responsibilities? Of course not! So beyond the information radiators, a PM can ensure the team is effectively communicating broadly across the organization.

Another important point is communicating in ‘terms’ that the business can understand. Whether it is reports, data, videos, or whatever it takes to represent the teams’ progress and efforts.

The PMBOK!

I’ll even go so far in this post to say that many of the ‘traditional’ principles and techniques from the PMBOK shouldn’t be “thrown away” from an agile perspective. Let’s take the notion of critical path for instance. In larger agile projects, with multiple teams, there still are plans that evolve. And within that framework keeping the critical path of work in-sight across teams can be a crucial visibility point.

As can asking the team to manage risks, or creating a project charter, or establishing effective milestones for cross-team integration. So please don’t throw away or ignore these skills if you “Go Agile”. Just transform them (and yourself) a bit and then trust your instincts in the situations that emerge.

Wrapping Up

I want to wrap-up this post with caution though—traditional Project Managers DO need to reframe themselves and their approaches in an agile context. Throw away your templates and checklists that prescribe a specific approach to all projects & teams. Instead you must become context-based and situational in your approaches.

You must also engage your teams, not as an execution monitor or policy cop, but as a true partner.

I’ll leave you with the following two charts that nicely illustrate some of the focus and tempo changes that occur between Traditional & Agile PM activities.

So, Project Managers—may you navigate these waters well and engage with your teams. They NEED YOU!

Thanks for listening,

Bob.

Don't forget to leave your comments below.

As we close out the year, wouldn’t it be nice to achieve year-end results with critical projects?  As many companies and leaders get lost in the holidays, it is an opportunity for those who stay focused on the key priorities.  By no means should you forget the holidays and thanking your people for a good year; however, if you channel your efforts on the critical few, you could not only end the year on a positive note but also accelerate project results in time for year-end.

There are several keys to success in delivering project results; however, one simple yet secret weapon is follow-up.  The best plans are useless without follow through and follow-up. I've found it quite amazing the number of highly paid, intelligent leaders that do not value or do not make the time to follow-up. Why spend millions of dollars developing plans if you don’t plan to put in the work to make sure they occur?  So what are a few tips to ensure results occur?  1) Plan.  2) Prioritize.  3) Follow-up.

1. Plan:  First, develop a simple plan.  What needs to be done?  By who?  When?  What support is required?  It doesn't have to be fancy or use the latest technology (a scrap piece of paper with action items will likely suffice). This will provide the structure for your follow-up.  In my experience across hundreds of projects in multiple industries and geographies, working a simple list is the 80/20 of success
2. Prioritize:  Prioritize your follow-up. It isn't necessary to follow-up on everything. If there is one common mistake in today’s new normal business environment, it is getting caught in an endless sea of tasks in a survival mode.  Instead of going down that rabbit hole, think about what’s most important.  What can have the largest impact on your project between now and the end of the year? Next, follow up on only those priority tasks; for example, the critical path or the A priorities.  If you follow up on only the tasks that are key, the people related to those tasks will intuitively realize the implied importance and prioritize accordingly. Additionally, the more you are able to explain why the specific tasks are important, the more the people responsible for the tasks will understand and value them themselves. On the other hand, if you followed up on every task, it would just become a nuisance, and you'd likely be ignored.
3. Follow up:  Think function & not form. It doesn't matter whether you follow-up via email, phone, a fancy software or whatever. What matters is that you follow-up. You will achieve the best results if you change your follow-up style to the person you are following up with. For example, if you are following up with someone who reads email voraciously but doesn't typically talk on the phone, send an urgent email. On the other hand, if you are following up with someone who enjoys talking with people (regardless of whether he/she has email), pick up the phone.

When you follow up, make sure to follow up in advance of the due date on critical tasks and critical path items. This gives the person an opportunity to remember and plan for the task. I've found that 99% of the people will complete the task with this type of follow-up, whereas, without the follow-up, I might receive a 50% completion ratio, mainly due to conflicting priorities and busy schedules.

It isn't complex, expensive or requires capital investment to follow-up, it just requires a bit of energy, yet, it yields significant results. Why not close out the year with your project team celebrating a significant “win”?

Don't forget to leave your comments below.

In my last post, Collaboration in a Command and Control World, we looked at one project manager’s experience trying to guide a technology upgrade where the sponsor focused exclusively on time and costs.

In this post, we’ll look at the steps one project manager took to leverage a promising new technology while avoiding the pitfalls often encountered with new technology introductions. Thanks to reader A.R. for the details on this case.

The Situation

This U.S based financial services organization managed 401(k) plans for employees of small to medium size businesses. A 401(k) retirement savings plan allows a worker to save for retirement and have the savings invested while deferring current income taxes on the saved money and earnings until withdrawal.

The company’s product offerings allowed participating client employees to invest in a wide variety of popular mutual fund products. The client employees would call the company’s service staff to get quotes on funds and to place orders for new investments or changes to existing ones. The company had a web site that offered similar services but found that the volume of phone calls continued to increase with the growth in their business. It was posing an ever increasing cost burden on the organization.

While interactive voice response (IVR) technology is common today, in the early 21^st century it was an emerging technology. However, because it held such promise to address their challenge, the company decided to take the plunge.

The Goal

The VP, Customer Service, the sponsor of the initiative, after discussions with the CIO and senior technical staff, decided to wade into the then largely uncharted IVR waters. She launched a project to leverage the new technology to reduce the current and growing costs of their phone services.

Her goal was to deliver an IVR system that would support the quote and trading functions for client employees across the country and have it fully operational in one year. She was looking for a 50% rate of conversion to IVR.

The Project

The IT organization appointed a seasoned project manager. Because the company had no experience in the IVR arena, he knew trying to estimate the costs of the project would have been a fool’s errand. They talked to a number of vendors and early users to know that an effective solution was possible. But the costs quoted varied widely. So he worked with the VP to figure out what she could afford by looking at the expected reduction in current costs and slowing the cost growth rate while offering the same or improved service levels. Her target - $1.2 million with a 70% IVR usage rate. That would give her a 2 year payback.

The project manager, working with an assigned business manager, the $1.2 million cost target and two of the most likely technology vendors, developed a plan of attack that included the following key elements:

• Identify and engage key stakeholders
• Get stakeholder agreement on the dimensions of the change. That included clarifying the opportunity for the company beyond this particular application, the specific goals, requirements, benefits, locations affected, desired or required target dates, anticipated volumes and phasing and staging opportunities from a business perspective.
• Get stakeholder agreement on the quality expectations, including factors like security, authorization, ease of use, continuity, scalability, localization and audit trail.
• Also, with the stakeholders, firm up the economic justification including the overall economic impact (business, IT, clients, others), competitive advantage, strategic fit, competitive risk and project risk.

With a fully developed picture of the project, its impact on the organization, and buy-in from the stakeholders, the PM assembled a small team including an experienced and respected staff member from the Customer Service organization, a business analyst, a programmer analyst and a senior technical analyst from the IT Operations group. Together they developed an RFP that went out to the two IVR vendors who had helped in the planning plus two additional vendors that showed promise based on feedback on the systems they had delivered.

When the RFP responses came back, the content was vetted, rated, ranked and their proposals assessed against the $1.2 million cost target. One company stood out (one of the two involved in the planning effort) and was approached to deliver the required solution. During the contract negotiations that followed, it was also decided to rely on the vendor to do the application development and maintenance rather than train up internal resources to develop the applications and maintain them after implementation. This would avoid the risks involved in having a critical technology service being supported by a too small internal talent pool.

Once the vendor was selected and on side, the project proceeded with a five stage plan:

1. Develop an initial prototype focusing on the quotation function to test the integration of the technology into the company’s infrastructure and the required application interfaces and get stakeholder reaction to the speech recognition structure and sound.
2. Implement the full quote capability in one region of the country to ensure the system’s ability to support the local accents, assess the willingness of their clients to use the new service and refine as needed to address any issues. In this first implementation, clients would be given a choice of using IVR or speaking to a Customer Service consultant as before.
3. Roll out the quote capability across the country, region by region, assessing support for local accents and degree of use in each region and refine as necessary. The choice to use IVR or speak to a person would continue to be offered.
4. Develop and implement the full IVR trading capability and implement in one selected region as before to gauge effectiveness and appeal and revise as necessary.
5. Roll out the full trading solution across the country, one region at a time, refining as necessary.

The Results

The project was a terrific success. It was fully deployed across the country in 11 months at a cost of $1.1 million with IVR utilization at 75% and rising. Customer feedback was very positive, especially because of the extended 24 hour phone service window using IVR versus the old 12 hour service period.

The staged rollout allowed the vendor to tweak the application to be more sensitive to local accents and adapt the structure and content of the menus and messages to improve responsiveness, based on feedback. It also allowed the organization to target clients and employees in the region being implemented to introduce the new IVR service, encourage client employees to use it and explain how to address problems and provide feedback.

The staged rollout gave the business the ability to redeploy the Customer Service staff gradually over the 6 month rollout period, reducing the anxiety that is a normal part of business and technology change. Also, it gave the IT organization the time needed to integrate the new IVR technology into their infrastructure and operations and refine the application interfaces to improve IVR responsiveness. And, all of the stakeholders were thrilled with the outcome. It was a project well done!

How a Great PM Succeeded

This project manager did a number of things right:

• He leveraged Project Pre-Check’s three building blocks (even though he had never heard of Project Pre-Check).
  • He identified and engaged the key stakeholders, including the vendor and the clients.
  • He took them through a structured process that enabled them to stay interested and involved, allowed them to provide their expertise to the project from inception through completion and confirmed their agreement with decisions made at each stage of the project.
  • Finally, he leveraged best practices (the equivalent of Project Pre-Check’s Decision Framework) to ensure the factors that should be addressed to ensure success were, in fact, addressed.
• The staged, iterative approach he took to implementation effectively avoided the risks of a big bang approach and allowed the vendor and project team to adjust the applications, the environment and the internal practices based on real world experience.
• His work with the sponsor to help her figure out how much she could afford to spend on the project to achieve her financial and service goals (it’s call ‘Worth’ in Project Pre-Check’s Decision Framework) was a key success factor. It was a meaningful figure that drove all the project decision making from scoping, RFP and vendor selection, through implementation. It enabled the other stakeholders and project team members to make calls against a meaningful number they all understood.
• He managed to avoid the usual potholes and pitfalls usually associated with trying to leverage new technologies to deliver business value.

If you find yourself in a similar situation, remember to consider Project Pre-Check’s three building blocks right up front and put these points on your checklist of things to do so you too can be a Great PM, and your sponsor’s best friend.

In the interim, if you have a project experience, either good or bad, past or present, that you’d like to have examined through the Project Pre-Check lens and published in this blog, send me the details and we’ll have a go.

Don't forget to leave your comments below.