18 February 2010 by cjr.

Supporting Project Management with Systems Engineering

The state of the art in the technical aspect of systems development has evolved over the past few decades from some basic concepts, practices, techniques and tools borrowed from other domains into a sophisticated, structured engineering discipline called “systems engineering.” Supporting disciplined program and project management with rigorously applied systems engineering is the surest approach to successfully defining and managing the development and sustainment of complex, technology-based products and services. Integrating the two disciplines, project management and systems engineering, into a seamless set of processes, plans, work products, reviews and control events that we document and improve in a continuous but systematically controlled manner has proven to be the most effective way to implement this strategy.

User, Customer, and Developer Interaction

Government agencies and commercial information technology (IT) customers typically obtain software-intensive systems, hardware, facilities, and support by issuing contracts for services from commercial vendors and systems development contractors and suppliers of various kind. The government calls this approach “systems acquisition.” The customer’s role is to define what it wants to acquire, how it will go about acquiring it, and to plan and manage the effort on behalf of its end-users, operators, and support staff. Contractors bidding on these acquisition opportunities must demonstrate prior experience and success with both the products and services sought as well as with the management, technical, and support services required. The experienced IT customer realizes that it, too, must have the capability to perform its role effectively in coordination with vendors, contractors, and suppliers. Knowingly or not, the customer is in the lead, setting an example, for better or for worse. An immature, demanding, dysfunctional customer organization can render ineffective even a mature, high-performing contractor. What the customer organization does or does not do is just as important as what the system development contractor does or does not do. When one or both parties perform inadequately, the entire system development process is impaired. The best way we know how to resolve this situation is to plan and document what each will do and how and when they will do it. They keep their interdependent activities and work products up to date and synchronized. They refine their plans and methods as they learn more and more about the nature and challenges inherent in the product they are building and its intended operating environment. More and more government agencies and commercial companies have approached organizations like the Carnegie Mellon Software Engineering Institute, professional societies, management consultants, tool vendors, and other sources looking for solutions to the same types of user-buyer-supplier relationship issues.

Process-Based Management

The technology product and service industry as a whole has attempted numerous times to define, document, and disseminate collections of sound practice and specifications of product quality. These have taken the form of standards, specifications, methods, tools, books, and training and certification programs, among others. The state of the art in system development management has evolved into a relatively sophisticated set of models, standards, training curricula, guided experience, and performance evaluation using structured collections of proven best practices. Experience has shown repeatedly that careful planning, frequent, regular review by trained, qualified people, and meticulous control of product components as they are developed, is the best assurance of successfully defining and fielding a complex product or system today.

Despite the ever changing, ever more sophisticated forms of delivery and media, we have not found a more reliable approach to successfully managing the development, operation, and sustainment of complex, technology-based systems than the “plan-do-check-act” cycle. This concept resulted from the quality control research of mathematician Dr. Walter A. Shewhart. He conducted his research in the United States during the 1940s, 50s, and 60s. Since then, many others, most notably W. Edwards Deming, have broadened and elaborated it for specific applications. Simply stated, it is a four-step process used to control product quality during the process of development. The steps are to: (1) Plan: determine what needs to be done, when, how, and by whom; (2) Do: carry out the plan, on a small-scale first; (3) Check: analyze the results of carrying out the plan; and (4) Act: take appropriate steps to close the gap between planned and actual results. Then, repeat, starting at Step 1.

We document “what needs to be done” in the form of a process, that is, a set of steps to accomplish a defined purpose or to produce a product or service. Systems engineers translate the concept of “small-scale first,” into producing a prototype, model, or simulation, or conducting a pilot project, a trial run, before producing the full-scale version or initiating mass production. They build in regular review, measurement, and evaluation of the resulting work products and the plans and processes used to build them, then act to take corrective action as deviations from plans and expected results emerge―or as potential deviation is predicted based on quantitative analysis of actual results against the background of prior experience.

This is process-based management. Using a systems engineering process-based approach, planners, project managers, engineers, and other technical staff break the work of defining and building large, complex systems into more manageable, repeated cycles of these four steps. Making use of data-based insight into actual progress and quality of product components as they are being developed gives both project managers and technical managers the information they need to analyze to make informed decisions and to take timely corrective action as actual progress deviates from plans―which it inevitably does.

No Silver Bullet

Innovators and researchers are still looking for and proposing better approaches but, for now, this is the best we have found.

Posted in Project Management, Process Management, Systems Engineering | Print | 216 Comments »

28 December 2009 by cjr.

I stood waiting outside the Chief System Architect’s office having arrived a few minutes early for our weekly status meeting. I could not help but overhear the conversation he was having with one of his project managers. More specifically, I could not help overhear his voice raised in apparent exasperation as he told her how disappointed he was to be finding out only then that her project was late and would not be able to deliver its next product release as promised ― especially because it was already overdue and he had not been given any warning. You can imagine how he must have felt, as I learned later, as he would now have to go to his manager and their client managers with the bad news ― just as had been done to him. Of course, you’ll note right away, it was partly his own fault ― maybe even mostly his own fault.

While I felt sorry for the young woman toward whom his frustration had been directed, I knew how the typical Information Technology (IT) software development project was run in their organization. There was little planning, inconsistent monitoring, no control discipline, reactive management, a complex, documented methodology that was not enforced but a “state of the art” tool suite that senior IT management expected all projects to use (it had cost a lot and promised improved productivity and software quality). In short, the degree to which there was a project management discipline was dependent on the project manager’s individual experience. Only when projects actually breached their published schedules would it become known and reported. By then it was too late to recover gracefully, if at all.

So, what does this scenario have to do with processes? Predictability and insight. Paying customers have a right to know “how things are going,” how you are spending their money, and that they will get what they think they are paying for. Documented processes that are actually performed, measured, reported on, and regularly improved provide predictability. You can detect deviations and defects earlier before they can become catastrophic and unrecoverable. Most importantly, you have more lead-time to identify the underlying issues, develop a resolution strategy, re-plan, and formulate a feasible change either to get back on track or to provide a reasonable alternative for your management and your clients.

Early Warning System

Early insight into risk areas and issues allows managers time to formulate and take corrective action. Managers appreciate that ― even the difficult ones. When a project manager provides accurate, timely, complete activity and product status information repeatedly, even the bad news is easier to handle. After a while, you become an open, trusted source of accurate, timely, information and insight. You become more predictable and reliable. People know they can trust you to inform them of risks and issues in time for them to do something about it without embarrassment rather than having to clean up a mess that they themselves allowed to worsen, knowingly or unknowingly.

To be able to provide this kind of timely information, a project manager and team members need to collect and analyze work product and process information routinely as a regular part of doing their day-to-day jobs. The best way we know how to do this is to document our work in the form of processes and the structure of our work products in the form of templates, train our people on how and when to use them, and measure our performance using them and the quality of the resulting work products.

We start all projects (no matter what size ― really!) with a plan. Not just a time line, task list, or schedule, but a plan showing what will be built, by when, by whom, for how much, and the methods and tools that will be used. As soon as we draft the plan, we begin reviewing it with our management and our clients ― all relevant stakeholders. Do not forget project team members and subcontractors are key relevant stakeholders, too ― be sure you have the commitment to the plan of the people who will do the work.

As the project team executes the plan, we measure our progress, actual versus planned. We take corrective action as actual progress deviates significantly from that specified in our plan. All along, we review the status of our risks using the “triggers,” the measured indicators that we identified for each risk, emerging issues, work product quality and other process performance measurements. We report progress regularly to all relevant stakeholders, i.e., project team members, management, and clients ― their management, support organizations, and users or user representatives. If our progress deviates significantly from our plan, we formulate corrective action in the form of re-planning and we set about regaining commitment from our managers, clients, and all relevant stakeholders.

Keeping It Real

This sounds like a lot of work, you say. Let me address that concern with a question: “what else does a project manager have to do?” More broadly, “what else does a manager have to do that is more critically important?” The most critical role of a manager, in any organization, at any level, is to enable people doing the work to know what to do, to have the knowledge, skills, abilities, and resources to do it, and to get their jobs done in the most effective manner possible.

It is the manager’s job to set direction, remove obstacles, provide resources, and monitor progress, taking corrective action as necessary. Note that it is a leader’s job to recognize the need for change and enable the organization to adapt to it and profit from it ― but that’s a topic for a future posting.

If your organization routinely, as a primary part of its business, runs projects to develop products, IT software or otherwise, and you have not invested in documented work product templates, measured, trained project management processes, methods, and tools, then you are not managing your organization’s work effectively. Period. You have work to do.

Timely management insight into actual project status and evolving product quality does not happen by accident. It does not happen without management sponsorship. It does not happen without investment and oversight. Let’s get going!

Posted in Process Management, Support, Management, Process Improvement | Print | 188 Comments »

30 January 2009 by cjr.

In his recent comment, Gary Holt noted that “the basic components of a ‘plan’ must include 1) a description of what is going to be done, 2) when it is planned to be started and finished, and 3) how it is planned to be completed (mechanisms/steps used). It may also include elements to get to these three such as estimates, resources, training, stakeholders, etc.”

It has also been asserted that “it is not the plan but the planning” that matters most. This value and logic is part of the approach embodied in Agile Methods―team members getting together frequently to exchange relevant, current information on status, work plans, and recent changes in needs, understandings, and commitments.

Larger, or more widely dispersed, or more specialized but interdependent work groups require careful attention to communication and coordination, especially in the light of rapidly changing business and operating environments. Plans and planning to the rescue! Written plans record our planning related to understandings, commitments, communication, and coordination of effort in the context of continuous change. They need to be flexible, easily accessible, and easy to update, communicate, and coordinate. We should support them with automated development, maintenance, communication, and collaboration tools where appropriate.

The notions of abstraction and separation of concerns help to enable flexibility. As I wrote in an earlier posting:

“Processes are generic plans. So, what do you use processes for in daily practice? To plan. To create a specific plan. The steps in a life cycle process become the steps in a project or product plan. And, you use them to train people on what to do, and on the best way your organization knows how to do something important and mission-critical. In the plan you specify the end product, intermediate work products, reviews and coordination or synchronization points, intermediate and final releases, resources, interfaces, logistics, dependencies, and risks.

Rather than writing a plan from scratch each and every time you begin a new project, or initiate the development of a new product, or deliver another round of service, your processes define your approach (life cycle), phases, steps, and reviews along the way. You can create generic plans using your processes and tailor them to specific project, product, or service delivery needs with little wasted time and with greater certainty of benefiting from lessons learned, experience, and corporate knowledge.”

So, the “lowest” level of a plan can be a process description listing individual steps to be performed. This approach allows you to create a flexible plan as a sequence of processes and the resulting work products, events, or services. As Gary noted, we add specific details concerning “What” is going to be done, “How” it will be done, and “Who” will do it using “What” resources by “When,” i.e., a schedule.

In summary, a plan is a written agreement among team members and other stakeholders. It identifies what is going to be built or provided, how it will be developed in terms of the processes to be used, a schedule indicating when each process-based task, review, stage, or phase is currently envisioned to start and finish. It specifies who will perform each task and what other resources will be required in enough detail so that those who need to provide the resources, intermediate work products, reviews, and approvals can do their part in a time and manner to which they can commit.

Plans enable and support communication, coordination, and collaboration ― the three “C”s of effective human endeavor. Plans change and need to be revised regularly. We communicate and coordinate on a regular, systematic, controlled basis to keep plans in synch wtih reality ― and all stakeholders informed, able to re-commit, and able to continue collaborating. Stakeholders include managers, other workgroups, customers, and end-users.*

Having said all this about plans, do you know of a better way? Have you seen ways in which team of coworkers can effectively collaborate across time, distances, and disciplines that did not require a written plan? Only by asking ourselves this kind of probing question, exploring fresh approaches, and being open to the possibilities will we move our methods, tools, and productivity forward. Constructive changes to well-understood processes come primarily from those performing them in actual practice.

Thank you for reading TopBlog!

* Coming Up: Let’s discuss the relationship between our processes, our partners, and our customers ― especially demanding customers.

Posted in Process Management, Management, Process Improvement | Print | 169 Comments »

20 January 2009 by cjr.

Welcome new subscribers!

Today is January 20th, 2009, the U.S. Presidential Inauguration Day. I am in the Washington, D.C. Metro Area and I can tell you that the excitement in town is off the charts! I would like to offer congratulations and very best wishes to our new President Barrack Obama and Vice President Joe Biden and send thanks for their years of service to former President Bush and Vice President Cheney.

I would like to welcome and introduce one of our newest subscribers, Gary Holt. Gary will be a regular contributor to TopBlog. You will see Gary’s comments and postings from time to time. Gary is a fellow CMMI Lead Appraiser, a very experienced process improvement consultant, and authorized instructor. For more information, look up Gary’s web site listed in the TopBlog Links.

Gary has suggested that we spend some time talking about “plans,” as he notes that many people have asked for more insight into what process professionals expect to see when they are looking for plans. We will take on that topic next.

In the meantime, I would like to comment on Gary’s note that he doesn’t think there should be any difference between “processes” and “procedures.” Although I wrote that a “process” describes “what” should be done, while a “procedure” describes “how” to do something, I concur that processes and procedures are documented using the same form, format, and descriptive content — the difference is in the details, “what” versus “how.”  To paraphrase Gary’s comment, it is a matter of degree, that is, whether you are describing a high level lifecycle process, a mid-level lifecycle phase, stage, or functional area process, or a specific outcome like a work product or deliverable.

Look for more expert contributors joining in soon. Thank you for reading TopBlog!

Posted in Process Management, CMMI, Process Improvement, Introduction | Print | 194 Comments »

6 January 2009 by cjr.

A Few More Basics to Start the Year 

Welcome to the new year and, to those new readers who signed up during the Holiday Season, thank you.

Now that we have explored what processes are and how they differ from procedures, I would like to take one more short step back to ask another basic question: what do you do with a documented process? How do you use one in daily practice? Do you use a process description in daily practice?

Most people, when asked what you do with a process think it might be a trick question. But, it isn’t. Essentially, a process description is a plan - a generic plan. It is notional in the sense that is describes steps to be taken and decisions to be made but without specifying the person or people who will perform the work or when. So, a process is a template for a plan of action. Ideally, it would specify the best way we know how to do something, to produce a particular work product, or achieve a particular outcome.

In this way, when we go about producing a work product, we don’t have to wonder what it should look like, what steps we should take to build it this time, or what kind and level of quality we need to build into it and to check for before we can consider the product to be complete and fit for its intended purpose. In short, we don’t have to take the time to reinvent our operating methods every time we start a task. This adds up to a huge source of time and cost savings for tasks that are repeated over and over as an integral part of our business or mission.

If you expect to improve the way you build or deliver something over time, again and again, you have to gain some control over the steps carried out to build or deliver it. You have to carry them out as consistently as possible. You have to take the time to identify what mistakes you made, why you made them, and take corrective action. If not, there is little chance of being  able to determine which steps are the sources of errors and product defects. In short, you have to measure process performance in some way.

You can start simply by noting your errors, defects, and misunderstandings while executing a process, and correlate them to the step or steps in the process where they occurred. During process execution, you will have to take immediate corrective action to stay on course but, in the long run, you should modify the process description to check for and eliminate the errors and defects you made before you complete the process. In this way, you continuously improve your processes and adapt them to changing business needs, and to the types of defects you and your organization are apt to make at this point in time.

Of course, permanent process modifications should not be made without proper version control, verification, notification, and training. Done well, process improvement is a continuous, systematic, managed process in itself.

To go back one more time, processes are generic plans. So, what do you use processes for in daily practice? To plan. To create a specific plan. The steps in a life cycle process become the steps in a project or product plan. And, you use them to train people on what to do, and on the best way your organization knows how to do something important and mission-critical. In the plan you specify the end product, intermediate work products, reviews and coordination or synchronization points, intermediate and final releases, resources, interfaces, logistics, dependencies, and risks.

Rather than writing a plan from scratch each and every time you begin a new project, or initiate the development of a new product, or deliver another round of service, your processes define your approach (life cycle), phases, steps, and reviews along the way. You can create generic plans using your processes and tailor them to specific project, product, or service delivery needs with little wasted time and with greater certainty of benefiting from lessons learned, experience, and corporate knowledge.

Of course, you can also use process descriptions as a guide and reference in your daily work at the most detailed level. This is particularly useful for procedures where you want to perform a task a certain, specific way, using a well defined method or a tool, manual or automated, that you have been trained to use. Typically, work product templates, forms, and instructions should be part of your process or procedure descriptions, so that you can see what you are intended to build or deliver, and how to best go about it. A picture is worth a thousand words. What is the product supposed to look like? What are its pieces, parts, and sub-assemblies supposed to look like as you develop and deliver them? What kind of quality and integrity checks do you have to make along the way, i.e., “in process?” How should you measure the level of product integrity and quality? What should you do with the measurement data? If you have ready answers to these questions, you won’t have to waste any time thinking about what to do. You can focus your energy, creativity, and precious time on performing the job in the most effective way possible based on your own and your organization’s accumulated corporate knowledge and experience.

Okay, so, now you know the basic answer to the question ”what do you do with a process?” Can you think of anything else, especially those of you who work in high maturity organizations? In the next posting, finally, I will introduce three new panelists who will help me to expand on process-based management, process improvement, organizational change management, project management and systems engineering in practice. Thank you for your time. Please check back soon. Please share your comments, questions, and suggestions. Again, thank you. 

Posted in Process Management, Process Improvement | Print | 182 Comments »

11 December 2008 by admin.

Why “process?” What is a “process?” This is a good place to start. A common voacabulary is essential to effective communication, collaboration, and learning.

By now you’ve all heard definitions of the word “process” and its use in the business, manufacturing, and government sectors. It goes something like this,”a process is a set of steps taken to achieve a specified outcome.”

To set a stake in the ground and establish a starting point, we will refine the definition of “process” to be a set of steps that describe what must be done to transform raw materials or intermediate products into more refined or more elaborate intermediate products or a finished product or service in the most effective way we have learned to date. A process can be strategic and broad as in the case of a product life cycle model, more specific as in the case of a project planning process, at the work-product level as in the case of a process to govern the development of a software design specification or to conduct a technical peer review.

So, what’s the difference between a “process” and a “procedure?” A “procedure” is used to specify explicily how to carry out a step of a process. For example, if during project planning we want to be sure that a specific cost estimation method and tool are used,  a process step can refer the user to a cost estimation procedure. A procedure description looks much like a process description except that its steps are more detailed instructions on how to perform the process step. The methods, tools, and techniques to be applied are incorporated into the procedure step statements.

To govern when to apply a specific collection of related processes, an organization typically documents a policy statement and trains the personnel expected to perform or be subject to the process in the mandates of the policy, the steps of the related process, and in any relevant methods, tools, or techniques required to expedite the execution of the process. The policies, processes, training, methods, tools, techniques, the relevant knowledge, skills, and abilities required, along with other supporting artifacts and activities such as performance measurement, form a process management system.

Later we will discuss more on policies, life cycle processes, functional area processes, procedures, and the other elements of a complete process or procedure description and how to use them as components in a process management system. We will also discuss process management system architecture, organizational change management, and process performance measurement.

Thank you for taking the time to read this posting. Please add your comments or questions and let us know where you would like to take the discussion in the future.

Posted in Process Management, Introduction | Print | 250 Comments »

11 December 2008 by admin.

Welcome new registrants!  

In this tight ecomnomy it’s important that we give prospective clients the reassurance that their software investments will be spent on improving their operations, their customer and supplier relations, achieving their mission, and contributing to their bottom line, not on fixing defects and resolving problems.

To be able to accomplish this we have to work not only in our business but ON our business, that is, building an understanding of what we do that works and what we do that doesn’t. Then we must leverage the things we do well and correct the things we don’t - systematically, in real time. We outline the steps, that is, the “processes and  procedures,” we execute to produce our critical work products while measuring how long it takes, what kind of errors we make, and identifying ways to do it better and better with courage, humility, and transparency.

And who identifies these improvements? ANSWER: The people who perform the work, that is, those that execute the processes.

Posted in Process Management | Print | 124 Comments »

6 October 2008 by admin.

Welcome to TopBlog! 

We’re glad you stopped by. What you will find here are exchanges between thought leaders and experienced practitioners in the field of management and engineering process improvement, process engineering, and appraisals. We will also discuss methods, tools, techniques, and examples of good practice in the fields of complex systems engineering, software engineering, agile methods, program and project management, and integrated engineering management.

Please be advised that this is a moderated web log. We will review all postings and comments reserving the right to edit them for length and clarity and to discard those that contain abusive or profane language or subject matter that appears to be illegal or that may be offensive to other readers - and those that stray too far off topic.

Let us know what you think and what specifically you would like to see us discuss. Thank you for your participation and for all constructive criticism and suggestions.

- Carlo J. Rodriguez, Editor, TopBlog

Posted in Introduction | Print | 234 Comments »