Ruminations on Change Control October 22, 2014Posted by Edwin Ritter in Project Management.
Tags: Change, change control, process, project deliverables, project experience, project management
1 comment so far
It seems that no matter how much project experience you have, how talented your team is and how simple or complex a project is, there is one thing that will always be constant and that is change.
Previous posts of mine have dealt with setting up projects, closed loop feedback and the value of PMOs. Another basic process to define and get agreement on while setting up a project is how to handle change. The concept again applies to ITIL, Project Management and Lean Six Sigma areas. The level of process to use in review and accept/deny changes can be proportional to the complexity of the project. Simple projects don’t have many changes while complex projects can have multiple changes. This relates to the fact that we make decisions and plans at a point in time. As the project goes forward and we get smarter in the future, we may need to revise our plans and that can lead to change.
In fact, during the planning phase, the process details should be documented to submit a change, review and assess the impact to the project. There are as many ways to deal with change as there are organizations. Having a consistent way to deal with and manage change(s) to a project is essential when change occurs. This chart illustrates the basic concepts as just one example of the process. Using a common repository, change log or application to create the change record is a good practice also.
The PM works with the project team to provide an impact assessment and a recommendation on the change. That decision should be reviewed with the sponsors. Each change should be assessed for impact to the schedule, resources and budget. Here are six steps to control change:
- Record / Classify – capture the request and indicate what area(s) of the project are affected
- Assess – review the impact to the cost, schedule and resources to implement
- Plan – update project documents as appropriate based on the assessment
- Build / Test – execute the change and determine effect to the rest of the project deliverables
- Implement – include as part of the project deliverables and release at go-live
- Close / Gain Acceptance – complete the documentation on the request and communicate with the team and stakeholders.
Using the process framework provides a way to control changes for a project and the rate at which changes are generated. Here is where the process helps in that it provides a way to accept or deny changes. Completing an assessment of the change and updating plans result in data to support the resolution to the change request. Not all changes are created equally. Some can be rejected outright and from other requests, it is clear to see the benefits.
Last, during project wrap-up and lessons learned, the number of changes submitted and their resolution can provide some interesting insights. How many were submitted? Accepted? Did the changes requested indicate a gap with requirements? Was the project not planned properly? Was the design not fully thought out? Those questions and others can lead to animated discussions. The key is which ones to action and improve on going forward.
Of course, that could be a change request also. How do you manage and control change? Does the process impact your project in a big way? What happens if you reject a change? Comments invited.
SMART Requirements July 9, 2014Posted by Edwin Ritter in Project Management.
Tags: assumptions, process, project management, requirements
add a comment
I’ve been ruminating lately on the interplay of the following : assumptions, requirements and expectations. Whenever we interact, being a good listener and confirming what you heard are key to meaningful conversations. Segue to a snippet of dialogue from a favorite movie scene :
Man: “You’d better tell the Captain we’ve got to land as soon as we can. This woman must be taken to a hospital.”
Woman: “A hospital? What is it?”
Man: “It’s a big building with doctors and patients, but that’s not important right now.”
Which reminded me of SMART*. A quick search led me to this blog which captures what I agree with on the having clear, defined expectations and the big ‘R’ word, requirements. It should not always fall to the project manager to sort this out of course. Sponsors and customers can be SMART. Wouldn’t that be nice? Which implies process and management styles – a topic for a future post.
*Common definition for SMART: Specific, Measurable, Actionable, Reasonable and Timed
How often are your projects SMART? If you asked for that as a requirement, what are your expectations for a response?
In my opinion, requirements are the most under-rated aspect of most projects. In an unbelievable number of corporate projects they are completely non-existent and in the vast majority they are really no more than a paragraph or two of high-level requests which are unlikely to be delivered on successfully. In a very few of the countless projects I have worked on I have seen adequate, or an attempt at adequate, requirements. These projects, without fail, are the most successful projects that I have seen.
Why the passion, you ask? Without clear, complete and agreed upon requirements there is almost zero-chance, yes zero, that the project will be delivered successfully. And when I say successfully, I mean on-time, on-budget and matching the desired scope. Sure, most projects will get delivered without good requirements but you will see project delays (possibly numerous), budget overruns, and final scope that doesn’t satisfy the customer…
View original post 1,658 more words
Tags: coding, deployment methods, lifecycle, management, process, project management, projects, software, software development, software development lifecycle, software development teams, technology, tools
In my last post, I covered my recent efforts at software programming after a self-imposed hiatus. As a follow up, I wanted to talk about the development cycle. More specifically, the software development lifecycle. The most traditional development method is the Waterfall method. As it’s name implies, the lifecycle flows across phases with the result being a finished product that is tested to satisfy design requirements.
Deployment methods I have used include Waterfall and Agile among others and hybrids of these. As shown in the image, there is a feedback loop with testing that can introduce new/revised requirements. That starts the cycle over again, from the beginning. From my experience, there are two phases that seem to get short shrift. One or both of these typically get compressed due to project constraints and are sacrificed in order to stay on schedule. Those phases include Design and Test. What I have also found is that if you accelerate either of those, the project will reap a short term benefit. But, ultimately the project will not stay on track. Instead, the project will re-visit one or both phases, which causes waste, and any gains in time expected are then not delivered.
As a programmer, I admit I have squeezed several phases. My advice – whatever process you employ, don’t cheat it. Having a solid design ensures requirements are addressed and adequate testing provides confidence for success at launch. Whatever method you use, adhere to the diligence in each phase and then keep progressing forward. Each phase should be sized according to the project goal. Changes to existing code base can be minimal and have little design impact. Great! Testing should then focus on regression impact to ensure everything is working with new changes integrated cleanly.
Does your mileage match mine? Comments invited!
Ramblings on Work Units August 12, 2012Posted by Edwin Ritter in career, Trends.
Tags: estimates, job description, management, measure, process, project management, unit of work, work
add a comment
I am fortunate that in my career I have worked at both the management and individual contributor levels. The positions I held have mostly been technical roles in IT, Marketing and of course, Project Management Office (PMO). I have also worked at multiple companies and while there are consistencies, I have also encountered unique processes, tools and ways to measure units of work.
Those development and management jobs I have had require many skills. Common in this non-inclusive list are : effective communication, organization, detail focus, decision making, analysis (technical and business) and the ability work work well with anyone in the company. The way a unit of work is measured in these positions will vary, but at a fundamental level, work is work. Which bring me to the focus of this post.
Job descriptions provide some insight on the unit of work involved. I find it amusing the lengths some companies go to when posting for open positions. There should be more consistency in job functions and the work required within those roles. By that I mean the skills required should be equivalent and measured against a consistent standard. I realize they should be; some would say they are. I do not agree.
In some job descriptions, the unit of work can easily be discerned. Project Managers manage projects. Developers write code. QA ensures it works as designed. Each of those can be measured as a unit of work. The variance is in what tools and processes companies use to measure (assuming they do). Too often, the job description contains fluff about the company, what a difference you can make, etc..
Next time you read a job description, look for the terms that describe the essential unit of work. If you don’t find it, I submit it is poorly written.
I’m interested in how you measure your work. Do you measure your productivity with units of work? Have you used them to generate estimates? For yourself? For your team?
Ramblings on Cycles and Phases August 30, 2011Posted by Edwin Ritter in Project Management, Trends.
Tags: cycles, phases, process, project management
In a recent book review I read, the author proposed that the Big Bang might be cyclical. The premise is that given enough time, everything in the universe starts over again. Man, that is like, totally cosmic. That is a long cycle for sure. We have some time before the cycle is complete and begins again. Until then, the universe will keep expanding.
Having a repeatable cycle is also beneficial on a smaller scale. Like our daily routine. We humans are creatures of habit. Typically, we do not like change. This is especially true in business – we like having a predictable and repeatable process. There is the challenge to keep it from boring rote execution. Management types appreciate working with knowns as opposed to unknowns. Having that consistent process cycle is a good thing.
When managing projects, I like having distinct phases (i.e. – discovery, planning, execution, etc.). Managing phases and cycles across multiple projects can be challenging yet also very rewarding. I enjoy the interesting challenge of having a cycle of multiple projects in different phases. Those situations keep you focused!
I think we are entering a business cycle where things will accelerate. Companies that are properly positioned with resources and good business processes can take advantage with increased sales, market share and ultimately, profit.
What phase is your company currently in? When the boom cycle starts again, will you be ready?
Old and New Visuals for User Experience October 4, 2010Posted by Edwin Ritter in User Experience.
Tags: management, Planning, process, web design
When it comes to web design, User Experience (UX) is one area where I learned a lot and, came to appreciate the value of, early on in projects. Having a good UX design is a key success factor in a good web site. As the web is a visual medium, using a simple graphic to describe the site design elements is a wonderful thing.
Having the UX defined is typically an early deliverable and is useful as the project goes along. It may be tempting to minimize the time spent on UX. If you skimp on the UX, as with other project fundamentals, you will revisit it later many times until you get it right. Pay early in the project and allot the proper time required to get this as complete as possible. In a visual medium, good design can be an intangible thing. You know a good design when you see it. Trying to articulate what makes a design work can be simplified by using these graphics.
The classic image from Jesse James Garrett shows the elements involved in UX. This timeless visual is now 10 years old also and still relevant. I keep a copy of this with me constantly on web projects. When the discussion turns to UX, I often refer to this image to understand and help drive a solution.
Fast forward to our current gestalt with User Centered design and here is a great graphic that uses the familiar iceberg analogy.
There is a lot of information conveyed in this visual and includes the elements from Garrett’s classic UX. I like the progression taking a strategy to concrete concepts, showing how planning drives design and results in launch taking while into account the personas, user testing (!) and observation. Last, I really dig the various ways the user goals are shown. It gets to the intent of the site and who will use it – instruct (tell me), inform (show me) and reveal (involve me).
This visual captures a lot of the current best practices for web design. Notice that the design is agnostic on platform delivery. This approach on basic design concepts works for the web, mobile and tablet platforms.
Both old and new visuals are useful for UX (and information architecture) discussions to convey the concepts for a site ‘look and feel’ . Each clearly shows what is required in UX and helps ground everyone on how the site will be used.
Have another useful visual? What is your favorite?
Execution – Flawless vs. Good Enough June 17, 2009Posted by Edwin Ritter in Trends.
Tags: Execution, Flawless Execution, Lessons Learned, Planning, process, Team Performance
I attended an interesting talk today titled ‘Flawless Execution’. Interesting topic on getting improved and consistent performance from your team. The event was organized by the Rochester Small Business Council (SBC). Kudos to them for scheduling this event. The main speaker, from Afterburner Consulting, was a retired Navy fighter pilot who flew F-14s. He described how they plan each mission and the elements involved in the planning. The steps they use include :
For the armed services, that dedication and commitment to execute a common process is the difference between life and death. Literally. So it follows that having a debrief of what worked and what could be done better is a key part of that process. The speaker also stressed that during that discussion, it is nameless and rankless. That is, everyone involved, be they leaders, peers or subordinates, are candid and admit to mistakes. They also point out to each other improvements. It is win-win for each individual and also the team. It makes perfect sense and the candor for a subordinate to call out a squad leader on their mistakes – within the debrief session- is an accepted military practice. The team attitude is ‘I made a mistake, I will fix it’.
When the process is run with flawless execution, the result is a Win. Successful mission, objective realized. Live to fight another day. In the military, those aren’t cliches, they are the truth.
In the business world, having a common, repeatable and reliable process is a good thing also. Flawless execution by your team will lead to increased sales. It better, else what good is perfect execution if it doesn’t lead to sales? That is another problem. For now, let’s assume the team is working on the right things. Getting your team to be consistent where everyone knows their role can be trying at times. As a manager, having consistent team performance can be very challenging. There are lots of reasons for this admittedly and you control a good part of that. Some within a teams’ control; other things are beyond their control.
In business and in war, speed is a key enabler. For many, omitting the Debrief part of the process is tempting and easy to do. Roll the Lessons Learned into the planning – save some time. Works for awhile – until the Lessons Learned are gone. Then, a team repeats mistakes; does not learn, can’t pass on their knowledge to others. Lost opportunity, lower sales and things slow down. Not good business.
The speaker also stressed contingency planning – ‘What if’ scenarios. If the Squad Leader is taken out, what is the chain of command? If there is equipment malfunction, what is the backup plan? One all those elements are in place (steps 1-4 and contingency), then the team is ready to perform its’ mission.
The business consequences of not making a sale, losing to a competitor are not as drastic as in military combat. It is not life and death. We tend to use the military based cliches, but they never have the same intensity or impact.
All told, it is not a new process, not a radical way of managing. It is common sense. I have heard this in other forms in the past; I’m sure you have too. In the business world, we tend to make assumptions about these steps and the process in general. Not every team has SMART* goals. Getting everyone you work with committed to, and, using a common process can be an unrealistic goal. For most businesses, simply having a process is good enough. Some times, execution is good, others; not so much. From my experience, that is due to the corporate culture and management style. What is accepted behavior? How are people rewarded? Do they each have SMART goals? Don’t assume so.
Flawless execution requires everyone in the organization is using the same process in the same way. I have seen this in the past with ERP projects. Lead, follow or you’ll get run over because ERP is coming. Common process, common goal, common deployment of teams working on the same timeline. Works and there are lots of consultants willing to help you get there. 😉
Do you want your execution flawless or just good enough? Your choice and your teams’ also. Good luck.
*Specific, Measurable, Actionable, Realistic and Timed.