Can you Become Agile, When Managing Projects the Top-Down Style?

Andrew Filev , Monday, July 20, 2009
I posted on enterprise agility before, but recently, I came across some very interesting research data, so I decided to give this topic a different angle, taking the present economic conditions into consideration.

The ups and downs of our economy are enough to make any executive dizzy. Just look at U.S. Steel (X). In the second quarter of 2008, the company achieved record profits, yet in November, executives laid off 675 workers and postponed the construction of a new $450 million plant.

When the economy weakens, leaders are forced to link expenses to revenues. To accomplish this, they instinctively impose top-down, across-the-board solutions. Unfortunately, the latest research shows that this common strategy results in a 50-50 chance of damaging the company's long-term ability to thrive.

Nevertheless, there are organizations that shine in changing financial conditions. The most agile companies that are able to quickly shift resources and employees to meet changing demands find millions of dollars in savings and often emerge stronger.

The meaning of “agility”

First of all, what does it mean to be “agile”? Enterprise agility (business agility) is a company's ability to rapidly and cost-efficiently recognize changes and adapt to them. In short, to be “agile” means to be able to make the right decisions and implement them fast. Making the right decisions is impossible without having real-time visibility into your company and the complete picture of your projects. Without this visibility, it would be like driving in the fog. You’re not sure what’s ahead of you, but you have to keep driving. That’s why you need the information that is in the minds of the employees dispersed across the organization. You need the knowledge coming from bottom-up. A constant dialogue between leaders, team members, stakeholders and clients is crucial. This fact is proven by the research conducted by Joseph Grenny, the co-author of three immediate New York Times bestsellers: “Influencer,” “Crucial Conversations,” and “Crucial Confrontations.”

During the last quarter of 2008, in the thick of the financial downturn, Grenny and his colleagues studied more than 2,000 managers and executives from more than 400 different companies. The results were remarkable. The researchers found that teams that foster focused, unified dialogue are 250% more likely to survive. Less agile teams are 360% more likely to miss millions of dollars in lost opportunities.

Is bottom-up the right solution?

So if an enterprise wants to be agile, should it use bottom-up management? Indeed, besides being a great way to get knowledge from the experts at the team level, the bottom-up approach to management on the whole, and to project management in particular, has a number of advantages. One of them is that it empowers team members to think more creatively. They feel involved into the project development and know that their initiatives are appreciated. The team members’ motivation to work and make the project a success is doubled. Yet, we all know that the bottom-up approach is often criticized for a lack of clarity and control. To be able to execute your decisions fast, you need to keep a tight, top-down control on operations. Otherwise, you may miss an important opportunity.

What’s the right solution then? The best way is to find a balance between the two and take the best practices from both of them. I once wrote a post about taking the best from the two approaches (bottom-up and top-down) to project management.

So to be agile, you need to be able to blend top-down control with bottom-up agility in a "Ying and Yang" style. Later in this blog, I’ll continue to develop my ideas on how this can be done by upgrading your project management practices to “Project Management version 2.0.” Now, I’d love to hear your thoughts and answers to the following questions:

•    Is agility important?

•    How can we make a company more agile?

•    Do project management practices influence the overall enterprise agility?

•    Have you tried blending top-down and bottom-up in project management?


Jump into the comments section and share your vision.

Comments (11)

  • Glen B. Alleman, Monday, 20 July, 2009
    And what are the chances of success for the alternative? Are there statistics for success using Pure Agile for the same class projects?
    Without those statistics, this is called a "one sided estimator" and is pretty much worthless.

    Now there is a successful approach for enterprise class projects.
    1. Define the needed business capabilities
    2. Define the next itertaion's (rolling wave may include many itertaions in the Scrum sense) techncial and operational requirements
    3. Define the Work Packages through which these requirements will be delivered.
    4. Hold the Work Package Manager accountable for the delivery of the contents of the Work Package.
    5. Use Scrum or your choice of agile development to get the deliverable (usually only one) out the door and into the hands of the users.
    6. Repeat until complete

    The top level capabilities plan, and the measure of progress in units meaningful to the stakeholder (usually money) as the top level framework - while providing flexibility and adaptability to the lower level work efforts is how enterprise projects can succeed.

    It is also how the US Department of Defense assured major programs have an increased chance of success.

    Both are needed, but it starts at the top with the clear and concise description of the business capabilities needed to succesfully deliver on the mission and vision of the system. Without that and way to assure all work is towards that - the 50/50 chance is likley for agile as well.

    Glen B Alleman
    VP, Program Controls
  • Eric, Monday, 03 August, 2009
    Glen,
    It looks like a valuable comment, but were you really commenting on this post?
  • Glen B. Alleman, Monday, 03 August, 2009
    Yes,
    Bottm up has little chance of becoming connected with the corporate strategy. It's a none starter outside of small organizations in the absence of some type of governance.
  • asheesh mehdiratta, Wednesday, 26 August, 2009
    yes this is what we have been experiencing where a balance works best for the organization though there are struggless if it is only topdown or bottoms up as highlighted in my post - http://agilejourneys.blogspot.com/2009/04/bottoms-
    up-agility.html
  • Kelly Waters, Wednesday, 26 August, 2009
    I love the idea of "upside-down management" - it's really empowering and in my experience delivers great results! I posted on the idea here on my blog, where you can also find tons of free information on agile project management and agile methods:

    http://www.agile-software-development.com/2007/07/agile-managers-need-to-turn-their.html

    Kelly Waters
    All About Agile
  • Andrew, Wednesday, 09 September, 2009
    Thanks for your comments.

    I agree that bringing bottom-up practices into large organization is a serious feat. How easy it is depends on the scale you are trying to achieve and on corporate culture. As all change management, it requires patience and skills. But it's clearly doable in many cases. For example, software development departments in many companies transitioned from top-down management to a blend of top-down and bottom-up management in the latest years, even in such traditionally top-down companies as IBM.
    I've recently published a slide deck on the topic at http://www.wrike.com/projectmanagement/08/24/2009/Project-Management-2-0-Is-Getting-Traction

    Regards,
    Andrew
  • Glen B. Alleman, Thursday, 10 September, 2009
    Andrew,

    The feat at IBM is localized. I live within a mile of IBM Global Services here in Boulder Colorado. So when yousay IBM, you must state not only what business unit(s) but what organizations within the buisness units.

    There are many examples in our domain where bottom up and top down agile development processes have been successful. But both are needed. Qwest (in Denver) is an example of deploying agile in "some" business activities, while traditional waterfall remains intact in others.

    Over generalizing a firms name as "doing agile" needs more qualification to be credible.
  • Andrew, Thursday, 10 September, 2009
    Hi Glen,

    The state of affairs at IBM's soft dev in 2008 is summarized at http://www.infoworld.com/d/developer-world/ibm-promotes-agile-development-953

    By the way, I wouldn't focus this discussion on agile software development vs waterfall software development. Waterfall process might have a lot of bottom-up practices built-in. Take estimation: bottom-up feedback is crucial there for building a realistic schedule.


    Regards,
    Andrew
  • Glen B. Alleman, Thursday, 10 September, 2009
    Andrew,
    I stand corrected.

    If you classify RUP as agile, then you are correct.

    However, I would not classify RUP as agile, simply because of the level of formality needed to perform the processes. Nor do I think would the Agile Alliance folks consider RUP a member of their little club.

    I'm very familar with how RUP is rolled out at Qwest here in Denver. IBM renamed it to QSDP and inlcuded "some" true agile (scrum like) processes, and retained many of the traditional processes for project that depend on them.

    The first tier guidebook is 200 pages thick - doesn't look very agile to me. The same RUP procesess are used at another client of ours build flight management software. They use the same tier one book unchanged.

    RUP = Agile?
  • Andrew, Thursday, 10 September, 2009
    Glen,

    Thanks for the insight!

    IBM are big boys and should be able to comment on the data they publish and naming they use. It might be better to challenge them on their own blogs, as that will give them a courtesy of reply. In any case, they have to listen to their customers and employees, that’s the basic and very simple principle of leveraging bottom-up information. If they do – they’ll evolve and thrive, if they don’t, they’ll lose market share.

    Cheers,
    Andrew
  • Glen B. Alleman, Thursday, 10 September, 2009
    Andrew,

    The IBM site is a marketing release, not a detailed technical description of the work processes.

    But I'd suggest "telling IBM what they should or not be doing" might be a bit presumptous. I have friends and neighbors who manage groups at IBM GS, and even they have difficulty getting the story straight about what they do or do not do on any specific project other than use RUP in some way.
comments powered by Disqus
Andrew Filev

Andrew Filev is an experienced project manager and a successful entrepreneur. He has been managing software teams since 2001 with the help of new-generation collaboration and management applications. The Project Management 2.0 blog reflects his views on changes going on in contemporary project management, thanks to the influence of collaborative web-based technologies. More >>

Get Updates