It is popular to make a list of maxims for developing products, managing projects, or managing business processes. Some are based on experience, some based on surveys, some based on principles and practices of a profession.
Here's mine based on counter examples of the sole contributor paradigm. The sole (or small group) contributor paradigm means maxims gathered from personal experience from a person's engagement on the job. One example for the sole contributor, used without permission and with full attribution is Woody Zuill's list. There are others Five Project Maxims, 18 Maxims of Successful IT Consulting and other. But I like Woody's framework best, because his topics fit best with our processes on complex, mission critical, software intensive programs and the hands on integration with process. Although Woody would likely not agree, both technical skills and formal process frameworks are critical success factors in any sufficiently complex domain - both are needed.
Doing the work is guided by the Strategy and Performance Goals of the needed Capabilities.
Without a clear and concise understanding of what DONE looks like in Measures of Effectiveness for the needed capabilities, all the project work has no home. It's just a list of features or functions captured by the development team from the customer or product owner.
It's the capability to accomplish a business strategy that defines the mission and vision of the project. Why are we doing this project? How will we recognize we've accomplished our mission? The capabilities delivered by the project starts with the fulfillment of Critical Success Factors. Which in turn implements a Performance Goal in support of a Strategic Objective that measurably benefits the business or supports a mission.
Responding to Change is impossible unless the system is easy to change, easy to maintain, easy to fix, and easy to enhance.
The ability to easily change a product or a process starts and ends with the architecture. This understanding began with Notes on the Synthesis of Form, Christopher Alexander, 1964. It's the architecture that enables the change, assuring that coupling among the components is minimized, cohesion between the static and dynamic processes is maximized, separation of concerns is traceable to all architecture decisions. If you're developing these as you go - allowing them to emerge - you're going to be disappointed when you discover your product is coupled in ways you didn't know, has weak cohesion among it's parts, and has cross cutting concerns which result in a tangled mess when you start to make changes.
The notion that the best architectures emerge are suggested by those not working on complex systems interdependent components, but on systems with lower levels of compelxity between the components. Imagine an enterprise ERP system, a software intensive manufacturing system, the 32 flight and weapons computers on the F-35, the multiple levels of interaction of Future Combat System (I worked the rebaslining of the IMP/IMS for Class I), and process control system found in a nuclear power station.
Now ask, would you like the architecture of these software systems to emerge as the development takes place?
Here's where to start for architecture in the enterprise IT domain. There are architectures for realtime embedded systems as well. For defense systems DoDAF is the architecture framework. So when you here responding to change ask - what's the mechanism that allows you to do that, when the system you're working on is complex, high risk, critically important - say banking, navigation and control, oil & gas supply chain, electric power generation and delivery, health care, drug development, retail, transportation? You get the idea
The notion of Question Everything ignores the fundamentals of every professional process improvement paradigm.
Working on projects is not about the needs of the individual. It's about the needs of the whole. Personal desires must be subordinate to the needs of the mission success. It's not about you. It's about the customer and the governance framework in which the customer operates her business or fulfills her mission.
Questions are great, you can learn at lot from questions. But questions asked without doing your homework are a waste of your time and those you are asking the question to. Go do your homework. Learn about ITIL, COBIT, INCOSE Systems Engineering, SEI, and other professional frameworks first. Then you'll have a basis for your questions. Then start with the root cause test for your questions. When someone says those haven't worked in their experience, don't just ask the 5 whys, seek the root cause.
The Why's approach may be able to reveal the symptoms. But to get at the root cause a deeper assessment is needed. One based on a process framework. A place to the Whys to land. Why didn't the work team follow the established test procedures? Why didn't the customer establish a set of needed capabilities before we started developing stories for the software development effort? These whys then reveal the root cause. The whys need to have actionable outcomes, not just the question. 1st graders can ask why.
Process improvement needs to ask why, but it can only deliver value when there is an actionable answer. No actionable answer in units of measure meaningful to the decision makers? The question everything paradigm is Muda (waste).
Working Product is product that meets the Technical Performance Measures (TPM), the Measure of Performance (MoP), and Measure of Effectiveness (MoE) as defined by the Concept of Operations (ConOps), Statement of Objectives (SOO), and Statement of Work (SOW).
Without stating these attributes of the working product there is no way to tell if it is the right working product. Right for the needed capabilities. Right for the strategy. Right for the technical, operational, and performance requirements. Simply saying working product in the absence of these measures is ignoring the large context of effectiveness and strategic value. When we hear many software features have little value, we can only determine that if the planned strategic value is defined and tested along the way. This is NOT Big Design Up Front. It is the core of strategy making.
But the notion of having working software be put to immediate use needs a domain and context for it to be useful. Otherwise it's just another platitude of the agile vocabulary. Working on orbit for a Navigation and Guidance computer may not happen for 9 months. That's the time it takes to get to Mars. So working needs an operational definition. Working in the full fidelity emulator of the space craft. Working in the complete Verification and Validation (100% thread coverage) of the emergency shutdown system. (I was one of gthe orginal architects of this system). Working in the full transaction processes system test bed.
Crunch-time is a symptom of harmful and counter-productive attitudes.
It's got nothing to do with attitudes, and everything to do with competent and mature business management and processes. Newspapers have crunch time every day, sometime twice or three times a day. Banks have crunch time every month. Surgeons have crunch time once they make their fist cut. 3 miles out onto a hot LZ in I-Corp, 1969, is crunch time delivering critical supplies to Fire Base Rip Cord. Flying to New York City has crunch time every time the 777 pushes back from the gate at LAX. It's not attitude, it's competency to manage in the presence of uncertainty and deliver as promised because you've been trained, have experience and a support system. But in the end it's the process. Process rules.
Knowing the capacity for work starts with knowing the demand for work. Throughput can only be determined if you know both demand and capacity. Then and only then, can you add margin for the irreducible uncertainties. And reserve for the reducible uncertainties.
We are only innovators of our process if we are capable of providing the innovative solution within the governance framework of our business.
If it ain't broke don't fix it. If it's broken first find the root cause and fix that cause. Rarely in modern business is the a broken process that didn't work right at one time. A critical success factor for all process improvement is to determine the root cause of the failure. Then and only then examine if there is a process problem. If so, fix the process. If not, fix the application of the process. Stop wasting time looking for solutions to the wrong problem.
The object of all projects is to deliver value to those paying you to do the work.
Writing software for money is not the same as producing art for money. If you're producing art for money, you're probably not a very good artist. If you're treating your job of producing value for money as art, you're probably not getting a lot of repeat customers.
Customers bought the capability to do something, they only care if you're self-actualized if they are a relative. Customers are happy when you've fulfilled their need to possess a capability for the expected cost on the expected day. There must lots of opportunities for participants on a project to receive personal satisfaction, grow together as a team, increase their skills, and even be innovative - but the customer rarely is willing to pay for that directly. It better be wrapped in the overhead rate. Good artists copy, great artist steal - Pablo Picasso. Good firms hire people already prepared to succeed. Read Making the Impossible Possible: Leading Extraordinary Performance: The Story of Rocky Flats for specific actgionable advice on doing all the things needed for success, including all the people processes. The abstract is here.
The more we understand that improvement is hard work. There is no free ride.
Nobody Ever Gets Credit for Fixing Problems that Never Happened: Creating and Sustaining Process Improvement is a start. They suggest less than 10% of the firms adopting Toyota's TQM actually apply it properly. This loops back to the question everything nonsense, when the questioning is uninformed by the missing root cause analysis of the dysfunction. The source of Dysfunction in the workplace must be determined before any suggestions for improvement can be made. Stating something is the smell of dysfunction is like stating what's that rotten smell as we drive by the recycling center/ Look out the window and see the source. Find the source before doing anything.
At the end of the day successfully managing projects is hard work. But there is plenty of advice. This is one of my favorites.
