
In this three-day seminar, Principals of the Atlantic Systems Guild: Tom DeMarco, Peter Hruschka, Tim Lister, James Robertson and Suzanne Robertson reveal thought processes that drastically improve your ability to achieve project victory.
In three days of this seminar, the Principals of The Atlantic Systems Guild will show you the necessities of project success. These include:
New rules for a new era: For most of the last two decades, we've been focused on process, cost reduction, and implementation quality. These trends have by now run their course. Today's priorities have everything to do with the mesh of complex assemblies of software. Yesterday we were concerned with programs, but today is all about systems. Huge systems. The secrets of building such systems are not to be found in our methods, but rather in our social structures. And it is these that we need to re-construct, almost from scratch.
Behavior patterns are at the heart of what we call “Organizational Culture.” By calling it culture, we tend to write it off as unmodifiable. But focusing on the behaviors that make up a culture, gives access; patterns are consistent, often almost invisible ways of acting, but they are not immune to change. In our ongoing attempts to become ever more effective, we have improved everything but culture. We at the Guild believe that project patterns, good and bad, trump best practices, and so any IT organization attempting significant improvement must confront its own prevailing patterns. During this conference you have an opportunity to discover, describe, and name, your organization’s patterns.
Projects go right or wrong, almost from Day One. In too many cases, the game is lost before the heroic efforts even begin. Death March projects are marching toward death, not because they are failing to progress, but because they have set goals that cannot be reached. These goals are not flawed simply for being too ambitious. Rather they are flawed for being vague or internally inconsistent. The inconsistencies are hard to spot because they lie in the project's "conflict space," where stakeholders have varying visions of what would make the project succeed. Being able to identify project level and individual “win conditions” and “fail conditions is the key to aligning all from the beginning.
You solve the problems of a new project.
A project is not just an intellectual endeavor; it is a community intellectual endeavor. These communities (teams, project groups, cross functional units and the organization itself) are subject to behavior patterns, some of them immensely constructive while others are sure to drain the energy out of the community. Given that the sum of its behavioral patterns is the community’s culture, learning to recognize a few key patterns becomes a key management task. Familial and supportive cultures can achieve more than flawed cultures, even when the flawed ones have better skills. Encouraging the good patterns and defeating the bad ones is, in a nutshell, good management.
Is it possible to be simultaneously risk averse and yet inclined to take far too much risk? You'd like to say no, that such would be a contradiction in terms. But projects everywhere are proved to have taken on schedule risk that boggles the mind, while at the same time, declining to accept the risk of building something truly transformative. The result is a project that is late to deliver a product that disappoints. This is a double failure of risk management.
Requirements are the most crucial ingredient for successful projects, and yet they are probably the most misunderstood part of systems development. Requirements specifications tend to be large, unreadable and usually unread documents. But the irony is that willing and able people write these documents. Unfortunately, they do so because they misunderstand the real objective of the requirements process.
The size of the systems we build has, on average, increased almost exponentially over the past twenty years. Yet during this same period, our approaches to system building have changed only modestly. Some of the methods of the 90s – still in use today – are simply swamped by the size of the systems we’re building today. This leads us to a drastic reconsideration of the need for and methods of collaboration.
Most organizations have competent project management and they know how to implement and test their systems. We know this from the huge amount of working software that we have today. Many of these organizations have also learned that the effort put into requirements is repaid when the right and appropriate software is built.
However, many of the same organizations fail to grasp the relevance of system and software architecture. Designing a software system without considering the evolutionary path that the system (and its offspring) will follow after delivery is the essence of short-sightedness. Yet we do it all the time. Being a great architect is much more than having vision in the first place; you have to learn to protect that vision in the rough-and-tumble of schedule pressure and project politics.
You decide and share the organizational and project patterns of behavior that most affect your projects.
Most systems are improved incrementally—they are made faster, smaller, more intuitive, cheaper, and so on. However, systems that are improved only incrementally are almost always doomed by the arrival of an innovation that removes and replaces the original. Remember when mobile phones became incrementally smaller—which was what consumers were asking for at the time—and then the iPhone arrived and swept the small phones away. While we all accept that innovation is a good thing, most of us consider that it is “someone else’s job”. Many companies have processes and constraints that while not hostile to innovation, are definitely not conducive to innovation. The goal of this talk is to demonstrate that innovation is possible, preferable and can be achieved by most organizations.
You might think that organizations known for velocity have high velocity processes. Think again. The difference between those who get projects done swiftly and those who can’t is only distantly related to the technology they embrace. Much more important is the set of human factors that defines the group. This is another case of Sociology trumps Technology.
It is 2012 and a tiny minority of projects fit perfectly into a standard process. For a project to be truly effective and efficient, the process has to be modified to fit the specific situation in hand. Project complications are too commonplace to be treated only reactively. The Software Industry has spent years working on the generalities of standard processes; The Guild believes we need to focus on the project specifics.
The people who work for you and with you, the ones who build the systems that your organization needs, are craftsmen and craftswomen. What are the skills and talents and habits of the best of them? Some of this is obvious—they’re great analysts or great coders or great designers etc.—but what are the underlying skills and talents (and tricks) that enable them to be the best?
The seminar will be a mixture of presentations and group workshops
The seminar will be held from March 28-30, 2012 in Moscow.