When a more detailed schedule was NOT going to help a project go faster!

The case study requires a free Member account
Please log in to download the file. Don't have a log in? Register now, it's fast and free!
Log in to download this file

Username:  
Password:  



Abstract
What do you do when the team has tight deadlines, but is not meeting those schedule dates, and the boss reacts by asking for even more schedule detail as a way to "get things back on track"? (And by the way, the boss is also changing scope and priorities weekly.) This case relays how one CEO and team were able to take a step back, understand and acknowledge the real problems, and mutually commit to a new, more agile, but also less ad hoc development approach.


What this is

A case study about fast adoption of Agile techniques to resolve a team's issues with meeting critical schedule commitments, while being flexible enough to respond to ongoing new input from current and potential users. The case involves a situation where there's an existing perception of "what's wrong and how to fix it" that is not necessarily right or the full picture!


Why it's useful

Multiple aspects of this case are very typical, in terms of the challenges faced and the existing perception of what's wrong and what needs to change. What's useful and insightful is seeing how open this group was to examining the situation and then making some big changes to how their team (and the CEO!) operated; and seeing how the "assessment" situation was set up to engender cooperation and support.

This case is useful specifically for anyone struggling to meet interim feature-based schedule dates within a project and experiencing lots of requirements (feature definition) churn.


How to use it

If your team is facing issues with meeting schedule targets, especially interim dates during a project, read the case for what the underlying problems turned out to be for this team, and what aspects of their new requirements and scheduling approaches might help you as well. (And if so, see also our Agile page. We have downloadable resources for learning about and getting step-by-step instructions for how to introduce and use specific Agile techniques with your teams.)

If you just want to learn more about situations where Agile techniques are very useful, read it to gain an understanding of this team's situation, the underlying issues and warning signs, and ways to bring Agile techniques into a team if necessary.


About the Author
Matt Glei Matt Glei is owner of Know-how Consulting in Honolulu, Hawaii. He has spent his 30-year career in high technology and medical product development and operations, including 5-person start-ups all the way to 350 M$ high-volume businesses with thousands of employees. His background includes significant periods in Research & Development, Operations as well as Marketing. Matt has long experience in product development processes, project portfolios and strategic planning; he has also developed several Quality Systems compliant with ISO and FDA guidelines.

As different as company situations may appear, the fundamental performance problems remain the same. Matt provides performance coaching in areas such as collaboration, knowledge management, intellectual property, virtual teams, and program, project and risk management. Matt is certified as a Project Management Professional by PMI and is a Certified Scrum Master (Scrum Alliance).



Related Items
Blog: Are You Elegantly Solving The Wrong Problem?

Blog: Scrum is Not Difficult; Abandoning the Familiar Is

Checklist for Trying Out Agile on a Project
A checklist summarizing one proven approach (of many) for applying and learning agile methodologies on a single project, as an experiment.

Agile Technique Brief: Standup Meetings
This guideline explains how to use one common agile technique -- standup meetings -- to get team members into the habit of keeping each other in the loop without spending hours every week in endless, agonizing status meetings.

Agile Technique Brief: Requirements Cards (User Stories)
Agile methodologies like Scrum and Extreme Programming (XP) often build on "user stories" as a way of capturing and tracking feature requirements. This brief explains how to use the techniqueÑreferred to here as requirements cards in order to widen the horizon to customers and stakeholders.

The case study requires a free Member account
Please log in to download the file. Don't have a log in? Register now, it's fast and free!
Log in to download this file

Username:  
Password:  






©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy

Get Our Newsletter
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues.

Follow Us!
Linked In Facebook Twitter RSS Feeds

Got a Question?
Drop us an email or call us toll free:
888-722-5235
Learn more about ProjectConnections, our contributors, and our membership levels and product options.