Q2 - Our worlds collide in the Agile PM space where you work on BIG systems. A lot of people reading this will, I suspect, struggle to understand the scale of the projects you've worked on and how they've influenced your thinking. Can you tell us about some of the more interesting projects?
BIG likely has no real definition. What is BIG for a 300 person energy company here in Denver is small for NASA in Houston. What is small for that same energy company may be large of the 4 person wireless antenna company our neighbor owns.
BIG usually starts with multiple customers and multiple development streams. This usually means some type of Enterprise projects. Something used by everyone – or most everyone – in the firm. A Claims Processing system, an ERP system, a Document Management system. This also can mean that the “customer” is not really a person, but a process. The Land Management System in a mining company requires that all documents be managed according to the governance policies of the firm. “Customers” of Land Management have some, but not much say in how the system will work. Enterprise system are not Personal productivity systems. They belong to and are defined by Governance frameworks.
So when BIG is used, it may not just be the size of the code base, or the number of developers. But rather the impact on the firm’s ability to conduct its business.
For product development, Big usually means some kind of “system,” with multiple moving parts. A product where managing the interfaces between these parts is more important than the contents of the individual parts. The individual parts are important as well – of course. But if they don’t “play nice” together the product doesn’t work. This is the basis of the Systems Engineering view of software development and the management of that development.
No comments:
Post a Comment