Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
Software Development Blogs: Programming, Software Testing, Agile Project Management
Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
A team is a collection of individuals. This fact is important to remember because how each individual consumes and synthesizes information is as varied as the number of team members. However there is a finite set of learning styles to take into account. Learning styles not only impact how individuals absorb and remember information, but how they share information with others. While there are several models of learning styles, I have found the Seven Learning Styles to be useful in multicultural IT teams.Â Here is my interpretation of the Seven Learning Styles:
Visual â€“ The Diagramer absorbs information from pictures.Â This is the person that builds diagrams or draws pictures to understand a concept. Adherents of mind maps tend to fall in to the visual category. Walk around your department and look at how whiteboards are being used. In a meeting the person that jumps up and starts drawing when they begin to explain a concept is generally a visual learner.
Aural â€“ The Musician needs to hear the information they are processing. Pitch, pace and rhythm tend to important components in how this type of learner processes information. When the aural learner talks about concepts, they often combine sound references into the descriptions. For example, when attorney Johnny Cochran famously intoned â€śIf the glovesÂ don’tÂ fit, you must acquitâ€ť he was evoking aural techniques that helped make the point sticky.
Verbal â€“ The Talker needs to talk though the content they are trying to absorb. In many cases the dialog can occur internally. For example, I tend to game plan certain meeting scenarios beforehand by running sample conversations through my mind so I can anticipate how they will sound.
Physical â€“ The Builder builds models as a means of building an understanding of a concept. Experimentation is a form of physical learning you often find in an IT department. Physical learners build something that is tangible so they can develop knowledge. Â If the learners we were discussing were rocket scientists they might build model rockets rather than drawing pictures of rockets. Â If we talking about programmers we would expect them to create executable code rather than models or diagrams. True prototypes (throwaway proof of concepts) are means of hands-on learning. Physical learners in non-physical situations will use tactile words to describe concepts. I recently talked to a database modeler that described the model symmetry of the model he was working on.
Logical â€“ The lawyer builds knowledge by assembling facts and assertions into logical arguments that can be evaluated. The process that the Lawyer follows tends to build very solid bases of knowledge that are hard to challenge and disrupt. Â Logical learners because they tend to move from point to point it is more difficult for them to makeÂ large jumps that do not follow from point to point. To paraphrase Socrates: All programmers are human, Joe is a programmer, therefore Joe is human.
Social â€“ The Grouper prefers learning in group settings. The critical component for the social learner is other people. Â The interaction with others is an important part of processing. Interaction in groups includes verbal andÂ non-verbal communication and emotional support. Do you remember the person when you were at University that always organized the group study sessions? They probably fell into this category.
Solitary – The Introvert learns best by themselves.Â This is the type of person that takes the book home over the weekend and just figures it out.
Learning styles are not mutually exclusive. Â Each person usually has a predominate style and one or more secondary styles. I tend to the visual, but often augment pictures with physical experiments (whether writing code or brewing beer). The individuals that make up a team will have a mixture of learning styles. Each personâ€™s learning style influences not only how they acquireÂ knowledge, how they store knowledge andÂ also influence how they can retrieve that data. Â For example, music or sounds are a tool for aural learners (the musician) to gather information and then retrieve it. Â Many of us use have used mnemonics to memorize facts. When I was young I learned to play a piano. Â When I was learning to read music, my teach taught me the mnemonic, “every good boy does fine.” These are the notes on the treble cleft.Â Teams need to work together to accommodate and validate different learning styles. When team members are not aware of how others on the team learn they can often talk past one anther, which could reduce knowledge-transfer effectiveness.
One of the suggestions in #NoEstimates is theÂ slicing ofÂ work - either Stories or any word needed to indicate an agile projectsÂ chunking of the work - into small pieces. This of course doesn't actually address the issue of producing andÂ Estimate at Completion for the project. An estimate needed by those funding or authorizing the spending of funds to knowÂ how much and when.
ButÂ slicing is a process of reducing the exposure to uncertainty to a manageable size.Â Â It's the next level down's answer toÂ what's the value at risk? Make in small and reduce theÂ value at risk of not showing up on time and on budget.Â SlicingÂ answers the question, that has been around forÂ some time.
How long are you willing to wait till you find out you are late (or over budget, or it doesn't work as planned)?
The answer to this Â - how long - question varies according to the domain,Â value at risk, and other factors usually associated with risk tolerance. But it is a question that must be answered periodically (month;y for us) Recently this notion ofÂ slicing has been put forth as part of theÂ solution to theÂ estimating problem, which of course it's not. Since the size of the workÂ chunks only reducing the uncertainty of the variance. Both the aleatory (irreducible uncertainty) and epistemic (reducible uncertainty) will be less when theÂ exposure to the uncertainty is smaller. Beneficial to the project for sure. But the totalÂ all in cost and schedule are related to theÂ slicing size only by the cumulative variance of the parts.
It many be interesting to know, thatÂ slicingÂ is part of ANSI-748 Earned Value Management assessment by the Defense Contract Management Agency (DCMA). DCMA is the DOD agency thatÂ validates the Earned Value Management System's 32 Guidelines. DCMA performs a 14-point assessment of the Integrated Master Schedule (integrated because it is connected to the cost based) and the Performance Measurement Baseline (PMB) (the time phased planned budget for all the work).
DCMA Check 8 looks for high duration activities. These are know to cause issues with the exposure toÂ programmatic risk for the program. The 44 day number represents 2 working months. The work then passes through one accounting period (monthly submission of the Integrated Program Management Report). At the end of each accounting period an assessment ofÂ Percent Complete is used to calculate the Budgeted Cost of Work Performed (BCWP) - theÂ earned value for the tasks, works packages, and control accounts (funding buckets) for the program. 44 days may sound long for an agile software development project, but 44 days is short on a multi-year, many millions and likley billions of dollars of defesnse work.
Since the agile comminity is Â fond of sayingÂ there is nothing new here, while suggesting their ideas are new and unique, the aboveÂ clip is from the DCMA guide, long used in our defense program management paradigm.
So it is worth repeating theÂ principle of asking how long you are willing to wait before you find out something. The rule of thumb is to sample the status of the thing you are controlling are a rate twice your needed to control or determine a value. This is called the Nyquist rate from single processing. Signal processing is where IÂ grew up writing software for Fast Fourier Transforms, Finite Impulse Response Filter, Kalman Filters for particle physics data streaming off the particle accelerator. When I didn't have an orginal idea to finish my PhD studies, I switched to writing the same software for radar signals intelligence, and electroninc warfare systems. Same principles work for anyÂ control system including a management control system.
Just as an aside in the control systems paradigm, there is discussion aboutÂ monitoring and decision making from the information gathered from the monitoring. This is an Open Loop control systems. Without a planned value toÂ seek, theÂ SET POINT if you're using the room thermostat analogy,Â monitoring the value provide no value, since you don't know what you areÂ seeking the system to do. JustÂ monitoring is Open Loop, you've got numbers from theÂ system the room temperature or the number of stories produced, but no target to control against.
To have a closed loop system, you need aÂ SET POINT, a steering target, a goal, a desired outcome. Then the monitoring - sampling - can produce a variance, a difference between goal and actual - by which you cn take action. Raise or lower the temperature, speed up or sloe down the car, speed up or slow down the production of software outputs. Yes you can go too fast, the down stream user can't take the results and by the time they can, the requirements may have changed. This is theÂ Closed Loop Control.Â
When we last visited WhatsApp they’d just been acquired by Facebook for $19 billion. We learned about their early architecture, which centered around a maniacal focus on optimizing Erlang into handling 2 million connections a server, working on All The Phones, and making users happy through simplicity.
Two years later traffic has grown 10x. How did WhatsApp make that jump to the next level of scalability?
Rick Reed tells us in a talk he gave at the Erlang Factory: That's 'Billion' with a 'B': Scaling to the next level at WhatsApp (slides), which revealed some eye popping WhatsApp stats:
What has hundreds of nodes, thousands of cores, hundreds of terabytes of RAM, and hopes to serve the billions of smartphones that will soon be a reality around the globe? The Erlang/FreeBSD-based server infrastructure at WhatsApp. We've faced many challenges in meeting the ever-growing demand for our messaging services, but as we continue to push the envelope on size (>8000 cores) and speed (>70M Erlang messages per second) of our serving system.
What are some of the most notable changes from two years ago?
Obviously much bigger in every dimension, except the number of engineers. More boxes, more datacenters, more memory, more users, and more scale problems. Handling this level of growth with so few engineers is what Rick is most proud of: 40 million users per engineer. This is part of the win of the cloud. Their engineers work on their software. The network, hardware, and datacenter is handled by someone else.
They’ve gone away from trying to support as many connections per box as possible because of the need to have enough head room to handle the overall increased load on each box. Though their general strategy of keeping down management overhead by getting really big boxes and running efficiently on SMP machines, remains the same.
Transience is nice. With multimedia, pictures, text, voice, video all being part of their architecture now, not having to store all these assets for the long term simplifies the system greatly. The architecture can revolve around throughput, caching, and partitioning.
Erlang is its own world. Listening to the talk it became clear how much of everything you do is in the world view of Erlang, which can be quite disorienting. Though in the end it’s a distributed system and all the issues are the same as in any other distributed system.
Mnesia, the Erlang database, seemed to be a big source of problem at their scale. It made me wonder if some other database might be more appropriate and if the need to stay within the Erlang family of solutions can be a bit blinding?
Lots of problems related to scale as you might imagine. Problems with flapping connections, queues getting so long they delay high priority operations, flapping of timers, code that worked just fine at one traffic level breaking badly at higher traffic levels, high priority messages not getting serviced under high load, operations blocking other operations in unexpected ways, failures causing resources issues, and so on. These things just happen and have to be worked through no matter what system you are using.
I remain stunned and amazed at Rick’s ability to track down and fix problems. Quite impressive.
Rick always gives a good talk. He’s very generous with specific details that obviously derive directly from issues experienced in production. Here’s my gloss on his talk…Stats
I spend a lot of time doing two things: blogging and telling other developers the benefits of doing things like starting their own blog. (Occasionally I squeeze in a little bit of time to code as well. And my wife says I spend too much time answering emails and checking my phoneâ€”she wanted me to […]
The post What to Do When You Don’t Feel Like Writing and You Have Nothing to Say appeared first on Simple Programmer.
I call myself a Creative Networker. It is the most accurate and succinct description I could think of that wraps all the projects I am involved in. My business cards and personal website explain that Iâ€™m a writer, speaker, trainer, entrepreneur, illustrator, manager, blogger, reader, dreamer, leader, and freethinker. (I seem to have forgotten bragger in that list.) If I had to summarize my personal brand with three words I would choose creative, smart, and funny. But I would easily agree that brands are better defined by their observers, not by their owners. My readers might prefer to describe me as weird, blunt, and smug. It is all in the eye of the beholder.
Listen to the Software Process and Measurement Cast 283. The SPaMCAST 283 features our essay on user stories. A user story is a brief, simple requirement statement from the user perspective. User stories are narratives describing who is interacting with the application; how they are interacting with the application and the benefit they derive from that interaction.
If you would like to read the original blog entries that formed the basis of this essay they can be found at:
Get in touch with us anytime or leave a comment here on the blog. Help support the SPaMCAST by reviewing and rating it on iTunes. It helps people find the cast. Like us on Facebook while you’re at it.
Next week we will feature our interview with Evan Leybourn author of Directing the Agile Organization. We discussed agile business management. Agile is not just for IT anymore!
I will be facilitating a ½ Day tutorial titled Make Integration and Acceptance Testing Truly Agile. The tutorial will wrestle with the flow of testing in Agile projects and will include lots of practical advice and exercises. Remember that Agile testing is not waterfall done quickly. I will also be around for the conference and look forward to meeting and talking with SPaMCAST readers and listeners. More confernce information ALSO I HAVE A DISCOUNT CODE…. Email me at firstname.lastname@example.org or call 440.668.5717 for the code.
I will be speaking at the StarEast Conference May 4th – 9th in Orlando, Florida. I will be presenting a talk titled, The Impact of Cognitive Biases on Test and Project Teams. Follow the link for more information on StarEast. ALSO I HAVE A DISCOUNT CODE…. Email me at email@example.com or call 440.668.5717 for the code.
I look forward to seeing all SPaMCAST readers and listeners at all of these great events!
The Software Process and Measurement Cast has a sponsor.
As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI's mission is to pull together the expertise and educational efforts of the world's leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.
Shameless Ad for my book!
Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: "This book will prove that software projects should not be a tedious process, neither for you or your team." Support SPaMCAST by buying the book here.
Available in English and Chinese.
Listen to the Software Process and Measurement Cast 283. Â The SPaMCAST 283 features our essay on user stories.Â A user story is a brief, simple requirement statement from the userâ€™s perspective. User stories are narratives describing who is interacting with the application, how they are interacting with the application and the benefit they derive from that interaction.
If you would Â like to read the original blog entries that formed the basis of this essay they can be found at:
Epics, Themes and Issues
Same as Use Cases and Traditional Requirements?
Get in touch with us anytime or leave a comment here on the blog. Help support the SPaMCAST by reviewing and rating it on iTunes. It helps people find the cast. Like us on Facebook while youâ€™re at it.
Next week we will feature our interview with Evan Leybourn author of Directing the Agile Organization. We discussed Agile business management. Agile is not just for IT anymore!
I will be facilitating a Â˝ Day tutorial titled Make Integration and Acceptance Testing Truly Agile. The tutorial will wrestle with the flow of testing in Agile projects and will include lots of practical advice and exercises. Remember that Agile testing is not waterfall done quickly. I will also be around for the conference and look forward to meeting and talking with SPaMCAST readers and listeners.Â More confernce informationÂ Â ALSO I HAVE A DISCOUNT CODEâ€¦. Email me at firstname.lastname@example.org or call 440.668.5717 for the code.
I will be speaking at the StarEast Conference May 4th â€“ 9th in Orlando, Florida.Â I will be presenting a talk titled, The Impact of Cognitive Biases on Test and Project Teams. Follow the link for more information on StarEast. ALSO I HAVE A DISCOUNT CODEâ€¦. Email me at email@example.com or call 440.668.5717 for the code.
I look forward to seeing all SPaMCAST readers and listeners at all of these great events!
The Software Process and Measurement Cast has a sponsor.
As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.
Shameless Ad for my book!
Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.
Available in English and Chinese.
I often find myself doing random calculations and I used to do so part manually and part using Alfred‘s calculator until Alistair pointed me at Soulver, a desktop/iPhone/iPad app, which is even better.
I thought I’d write some examples of calculations I use it for, partly so I’ll remember the syntax in future!
Calculating how much memory Neo4j memory mapping will take up
800 mb + 2660mb + 6600mb + 9500mb + 40mb in GB = 19.6 GB
How long would it take to cover 20,000 km at 100 km / day?
20,000 km / 100 km/day in months = 6.57097681677241832481 months
How long did an import of some data using the Neo4j shell take?
4550855 ms in minutes = 75.84758333333333333333 minutes
Bit shift 1 by 32 places
1 << 32 = 4,294,967,296
Translating into easier to digest units
32381KB / second in MB per minute = 1,942.86 MB/minute 500,000 / 3 years in per hour = 19.01324310408685857874 per hour^2
How long would it take to process a chunk of data?
100 GB / (32381KB / second in MB per minute) = 51.47051254336390681778 minutes
Hexadecimal to base 10
0x1111 = 4,369 1 + 16 + 16^2 + 16^3 = 4,369
I’m sure there’s much more that you can do that I haven’t figured out yet but even for these simple examples it saves me a bunch of time.
Several years ago, IÂ hiked the Inca Trail in Peru. The trek included three plus days of hiking, climbing, crawling, sweating and an occasional exasperated utterance. Each day presented me with a new set of challenges and tasks to confront and to overcome. In some cases failure was not an option with without endangering myself, fellow trekkers, guides or porters (or all of them at once). Each accomplishment brought its own value while moving us closer to the ultimate goal Machu Picchu. Meta-physically the process could be viewed as a form of ritual purification. The process presents the supplicant with a series of tasks and hurdles to overcome to bring him or her to a point where the larger goal can be grasped. The journey is an important part of reaching the ultimate goal. Taking the train to Machu Picchu would not deliver the same enlightenment as toiling for days to attain that goal. Both have a value and one or the other might not be an available option in every circumstance however under no circumstances should the value each delivers be confused with being the same.
The parable of the trek can be used in the process improvement arena. Organizations whose sole rationale for the journey is the goal, the approval or certification can easily be tempted to look for methods to â€śtake the train,â€ť in other words, to jump to the end without the effort between the beginning and the end. â€śTaking the trainâ€ť has made many faces: buying a set of processes and implementing them blindly, hiring consultants to define, develop and implement process improvement without your organizations intimate participation or outsourcing to an organization that already has the title or certification youâ€™re seeking. The scenarios are not valueless rather they provide significantly less value than derived from the ritual purification of the trek. Iâ€™m not suggesting organizations blindly blunder down the SPI path as a learning process:Â guides, porters and tools can help you make the journey in your own way. Making the journey in your own way provides the greatest possibility of learning, growing and transforming. The guides can provide best practices, templates knowledge and guidance however without making the journey these pieces of knowledge capital will not be easily internalized. It will be easy to view the requirements of change as external pressures to be resisted rather than embraced. Humans and organizations resist change primarily due to fear or complacency. The ritual purification built into the journey is a tool to break the complacency and transform fear into action; to incorporate the journey with all of its trials and tribulations into part of the solution rather than just an obstacle in the way of attaining your process improvement goal.
I finally got a chance to talk withÂ Miguel CastroÂ about fitness and diet and how he incorporates it in his busy life. Miguel has an awesome story about how he lost quite a bit of fat and replaced it with muscle. Full transcript below: show John:Â Â Â Â Â Â Â Â Â Â Â Â Â Â Hey everyone, welcome back to the Get Up and CODE […]
The post Get Up And Code 047: Miguel Castro Knows How To Stay Fit appeared first on Simple Programmer.
Is optimism a good thing?Â Optimistic people live longer and are typically happier then less optimistic people.Â Michael Sheier and Charles Carver report in Effects of Optimism on Psychological and Physical Well-BeingÂ that optimism may lead a person to cope more adaptively with stress. Â Unfortunately the personal benefits of optimism do not tend to expend to projects and teams.Â So why is optimism good for most of people while it is a problem for teams?
In people optimism is a great thing, but for project managers optimistic realism (defined as optimism balanced with â€śREALâ€ť data) is far healthier. Regardless of my plea most teamsÂ or leaders eschew realism and plan optimistically.Â We are trained to be problem solvers; trained that we can surmount any problem by sheer force of will, therefore we plan optimistically. Â Planning for optimism only counts when you define planning for optimism as a plan based on measured performance plus planned innovation.Â Innovation must be planned because projects cannot count on serendipity to achieve their goals and neither can teams nor an organization count on lightening striking twice without a plan and process to attract it.
Agile teams of all shapes and flavors need to separate how they view themselves from how they view their role.Â Personal optimism is great, but professional optimism should be replaced with optimistic realism.Â Realism is seeing the forest for the trees and planning to make sure you achieve your goals.Â A self-managing teamÂ must see risk, to predict the future and plan for innovation and change to deliver in a timely, accurate and efficient manner. TeamsÂ must focus on performance because they areÂ charged with delivering functionality while making a customer happy.Â It takes optimistic realism to deliver.Â In short:
Optimism without measurement and data as a balance is unrealistic.
Hey, it's HighScalability time:
Don't miss all that the Internet has to say on Scalability, click below and become eventually consistent with all scalability knowledge...
This week I was asked if I offer a discount for charity organizations for my new one-day workshops.
I said, â€śNoâ€ť.
I donâ€™t believe in discounts for charity for various reasons. But Iâ€™m also sure some people will hate me for saying â€śNoâ€ť when I donâ€™t offer a good explanation. â€śJurgen is such a bad selfish person! Boo!â€ť Well, yes thatâ€™s true. But let me offer you my thoughts.
There is a popular myth that theÂ estimating problem in Â software development starts with comparing software development to bridge design and development. This lays the groundwork that software development is not the same as any other engineering discipline and estimating can't be done for software projects
That some how the project paradigm is excempt from the Five Immutable Principles of every other project domain. These immutable principles are:
If we are building bridges the answers to these questions are pretty clear. We are Â bending metal into money in ways well established from the past. For software project, these questions still have clear and concise answers, although the answers are developed not from blueprints, but from other means.
Economics of writing software for money
If we accept these immutable principles of project success there are few other immutable principles of business and the management of a business that writs software for money. Either internal projects, where funding comes for the company, or external projects where the money comes from a customer.
First let's look at Barry Boehm's seminal workÂ Software Economics. Some have suggested this idea is outdated. They would be wrong, especially since that suggestion - being wrong - is not backed by any experience or reference of managing the balance sheet ofÂ for profit software project. Internal projects where the cost and cost perfomance is outside the persons management responsibility doesn't count.Â
Show me the money (that you have been held accountable for)
And buy accountable I mean, you lose you job when things go bad financially.Â
Now with the advent of agile software development, Barry's concepts from long ago need to be updated for iterative and incremental development. Barry by the way instituted the Spiral method in the DOD, replacing the Waterfall method, An recently instituted theÂ evolutionary method replacing the spiral method, starting with Section 803 of the National Defense Authorization Act.Â
Core business processes are still in place, not matter the software development methods. Those processes haven't been overturned by agile or any other process. We still exchange money for value. The rate of that exchange must be a positive ratio
Value / Cost > 1.0
must be positive if we expect to stay in business for long. Monetizing value is many times difficult up front. Monetizing the work effort may appear difficult to some, but in fact it is not as difficult as it appears. There are many tools, processes, books, training, professional organizations that have field proven solutions to estimating and managinf cost in the software development domain.
Back to the Future on Estimating Software Development Cost (and Schedule)
This approach comes from early in my career. A time by Barry Boehm worked at TRW, along with me and 1,000's of other. My boss, took usÂ young guns aside one day and gave us his standard speach on a pay day Friday.
Everyone take out you pay check. Look in the upper left corner. It says Bank of America and TRW and the branch address. That's NOT where the money comes from to pay you. The money comes from the US Air Force (TRDSS was our program). They pay us to deliver the Statement of Work items for the amount of money we said we woudl on the date (more or less) we said we would. Keep doing that - within the allowable variances - and you'll keep getting those check you can take across the street to deposit in your account.
Customer provides money to do the work needed to provide value. In the TDRSS case, provide theÂ internet in space. When the cost of providing the value exceeds the budget for providing the value, we loose money and likely go out of business.
Not knowing when you're headed for trouble on cost, schedule, or techncial performance is simply bad business. So having an estimated performance target toÂ steer against is mandatory for business success. It can't be any cleared than that. Without thatÂ steering target your project isÂ open loopÂ management and you'll be in the ditch before you can steer away from the ditch.ÂRelated articles Facts and Fallacies of Estimating Software Cost and Schedule
When you begin a change process it is sometimes important to have a reminder of the critical points required to start the journey. If you were getting ready for vacation the checklist might include identifying who is going and who is in charge, deciding on a destination, a map, hotel reservations and a list of people to tell you are going. Beginning a process improvement project is not very different. I have constructed a simple checklist with five of the most critical requirements for preparing to embrace a journey of change. My critical five are:
1.Â An Identified Goal
2.Â Proper Sponsorship
3.Â Sufficient Budget
4.Â A Communication Strategy and Plan
5.Â A Tactical Plan
The first item on the checklist is an identified goal. The goal is the definition of where you want to go, the destination in the vacation analogy. A goal provides direction and a filter to understand the potential impact of constraints. Examples of goal can range from something as simple as, â€średuce the cost of projectsâ€ť or as complex as â€śattain CMMI Maturity Level 5â€ť. The goal also sets the table for discussing all of the other items on the checklist, such as the required budget. One piece of advice:Â make sure your goal can be concisely and simply stated. In my opinion simplicity increases the chance the goal will be broadly remembered, which reduces the number of times you will need to explain the goal, which will increase the amount of time available for progress.
Proper sponsorship is next on the list. Sponsorship is important because it is provides the basis for the authority needed to propel change. There are many different types and levels of sponsorship. The word â€śproperâ€ť is used in this line item to remind you that there is no one type of sponsorship that fits all events and organizational culture. Examples of different flavors of sponsor include â€śthe barbarian.â€ť The barbarian is the type that will lead the charge, but typically is less collaborative and more a command-driven personality. Barbarians tend to be viewed as zealots who harness their belief structure to provide single minded energy towards the goal they are focused on. Having a barbarian as a sponsor can infuse change projects with an enormous amount of power. The bookend to the barbarian type of sponsorship is the â€śbureaucratâ€ť. Sponsorship from a bureaucrat is very different. Instead of leading the charge bureaucrats tend to organize and control the charge. They may provide guidance, but they rarely get directly involved in the fray. The examples show two different varieties of sponsorship each that will fit in different organizations. In a life or death situation I would like to have a barbarian for a sponsor, however if I was affecting incremental changes in a command and control organization the bureaucrat would make more sense. Remember sponsorship is important because sponsorship give you access to power.
Budget is next on the checklist. The term budget can cover a wide range of ground ranging from money to availably of human resources (effort). The budget will answer the question â€śhow much of the organizationâ€™s formal resources can you apply?â€ťÂ The budget that ends up being identified to support change is always less than what seems to be needed. Use this constraint as a tool to motivate your team to find innovations on the way to attaining the goal rather and a reason to rein in your goal.
The first plan I recommend building is an organizational change management plan (OCMP). The OCMP is a means to frame how your project is going to transform the future state of the organization. An organizational change management plan will integrate the project roles and responsibilities with the requirements for communication, training, oversight, reporting and the strategies to address resistance, and reinforcement activities. We will address concepts of organizational change management in essay later in 2009. The OCMP is a mixture of a high level map and how-to document that is critical to ensure you are as focused on how you are change the organization as to tasks required to define and implement specific processes.
Finally you will need a tactical plan that lays out the tasks you need to accomplish and the order the tasks need to be done. The focus and breadth of the tactical plan you use will be different depending on the project management technique that you use. For example if you use a time boxed technique like SCRUM your tactical plan will focus on identifying tasks for the current sprint based on the backlog of items required to reach your goal. Regardless of the planning technique used, a sprint backlog or detailed project schedule doesnâ€™t matter you must have a tactical plan or risk falling into random activity. Use the technique that conforms to your projectâ€™s needs and your organizationâ€™s culture. The bottom line is that you will you need to understand the activities and order they occur in to get to your goal.
Change is difficult to accomplish in the best of times and almost impossible if you fail to start properly. The simple checklist for change readiness described in this paper was developed and compiled to help you focus on a set of topics that need to be considered when beginning any process improvement project. Are there other areas that should be on the list? Can each topic area be decomposed into finer levels of granularity? I believe the answer is certainly and I would urge you to augment and decompose the list and further to share your results. In any case a checklist that focuses you on getting your sponsorship, goals, budget and plans in order can only help you start well.