By definition managing “big” development projects usually translates into “big” teams with “big” capital investments. Contemporary analysis of traditional IT projects indicates these big projects also have a high degree of failure risk. Many leaders believe having extensive reporting and oversight will ensure timely completion and reduce risk. However in meetings and reviews, confidence in outcomes is always debated and we tend to manage to worst case. I think it’s easy to look at the continuous software delivery of large social media companies and think the same can be achieved at a large enterprise. One big difference relies on the mission criticality of enterprise applications, especially in healthcare. Sometimes software development suffers from Parkinson’s Law, which is the adage that “work expands so as to fill the time available for its completion.” It’s best to attack Big with Small as in Small Teams. Project resourcing is non-linear - by doubling resources, you don’t double output. Large teams have inherent management overhead just to keep them going and it’s better to parse out the work. You have to delegate authority to your program leads. We have a concept of “staying on the reservation.” If you let your leaders know their decision-making levels, then they can confidently make decisions without wandering off the reservation. The voice of the customer has become a new buzzword in agile development recently. Augmenting development with customer feedback in real time using best practices from market research will result in better products from the get go. Design is so much more than just gathering requirements - design is everything! Utilizing DevOps and related technology tools will speed up delivery and support of the complete solution and you can move from a minimum viable product to a minimum marketable product more quickly. As teams learn, work and grow together, mutual trust will develop and competency will increase. Only through trust will team members feel secure enough in their role to be transparent with their abilities and ask for help early on before their work goes off track. A smaller team at a smaller table is a better place to work out those types of development challenges.