jump to navigation

Ruminations on Change Control October 22, 2014

Posted by Edwin Ritter in Project Management.
Tags: , , , , ,
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.

programming-change-management-processIn 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:

  1. Record / Classify – capture the request and indicate what area(s) of the project are affected
  2. Assess – review the impact to the cost, schedule and resources to implement
  3. Plan – update project documents as appropriate based on the assessment
  4. Build / Test – execute the change and determine effect to the rest of the project deliverables
  5. Implement – include as part of the project deliverables and release at go-live
  6. 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.

Advertisements

SMART Requirements July 9, 2014

Posted by Edwin Ritter in Project Management.
Tags: , , ,
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.”

smartWhich 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?

The Practical Project Manager

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

Ruminations on Software Development Life Cycle (aka, SDLC) July 18, 2013

Posted by Edwin Ritter in Trends.
Tags: , , , , , , , , , , , ,
4 comments

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.

sdlc_lifecycleDeployment 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, 2012

Posted by Edwin Ritter in career, Trends.
Tags: , , , , , , ,
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, 2011

Posted by Edwin Ritter in Project Management, Trends.
Tags: , , ,
2 comments

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, 2010

Posted by Edwin Ritter in User Experience.
Tags: , , ,
4 comments

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.

Elements of User Experience

Classic UX from Jesse James Garrett

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.

Elements in user Centered Design

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?

Social Media use in B2B – Case Study & Results August 31, 2009

Posted by Edwin Ritter in Trends.
Tags: , , , , , , ,
add a comment

Found this from a post on a LinkedIn group I subscribe to. Interesting account on how Twitter and other SM tools were used for a  recent B2B initiative. Includes Lessons Learned that are worth reading. Here’s the link.

Take aways include :

  1. There is a learning curve – don’t underestimate
  2. Training for new skills -have them before you need them
  3. Not as bad as it seems – the worst did not happen
  4. Catch up to competition – SM provided increased visibility with others and crowded the landscape a little more
  5. Blurred lines – between internal groups on who does what.
  6. Manage from the middle – very interesting concept similar to having decision made by those closest to the work. Trust your staff has the right skills and experience. Don’t wordsmith – not a good use of your time!

It’s great that the lessons learned are added here. Will B2B have increased use of SM? How does that change current SM practices?

Execution – Flawless vs. Good Enough June 17, 2009

Posted by Edwin Ritter in Trends.
Tags: , , , , ,
4 comments

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  :

  1. Plan
  2. Brief
  3. Execute
  4. Debrief

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.