Ramblings on Software Delivery February 28, 2016Posted by Edwin Ritter in Cloud Computing, Project Management.
Tags: release management, release management process, software delivery
add a comment
I expect there will be a time in the not distant future where software development will be easier. So we are clear, I mean predictable, common even.
While not fully equivalent, here is an highly simplified example.The electrical socket outlet is a common fixture found in commercial and residential buildings. This did not happen by accident. The generation of electrical power and subsequent demand caused a great deal of standards, regulation and common design elements. They were required and fundamental to broad use of electrical and ubiquitous availability.
Software best practices constantly evolve and there have been lots of advances from the 1GL, 2GL and 3GL days. Yet, despite those improvements, a recurring challenge on projects for me concerns the final product. By that, I mean delivery and all that goes with it. Not in any order, but these include customer acceptance, integration testing, launch, cut-over, final QA. From my experience, what should be common and predictable instead is anything but. Each project has unique challenges but the over all release process is the same.
And, yet. Here we are with 4 and 5GL programming and the fundamental challenges that remain to be solved. Code objects are inter operable; APIs are well understood but ad-hoc. Seems to me that there should be more common functions and libraries that provide a lot of the basics. And they do – to a point. But not at the same level as electrical outlet.
Perhaps the challenge is more with interfaces and data types (schemas). But I digress. Delivery and integration of software remains a crucial phase (see delivery above). Imagine a time when delivery is the same as generating power and connecting to the ‘grid’. Delivery is then driven by demand and usage among other things. Yes, cloud computing comes to mind and that has made things easier.
Which leads me to release planning using Agile practices. A good step forward toward common delivery. Getting more consistent release process is always preferred to ad-hoc. I have earlier posts about this topic and I expect there may be future ones as well. It is an evolving practice and gets better all the time.
ITIL outlines release management best practices. I know that the state of the art in software development will get to the electrical power example I mentioned earlier. The general consensus is we have achieved a basic process for delivery. Understanding current state, defined and consistent intervals,use standards and automate when and where ever possible are part of best practices.
What other challenges will remain going forward? How will standards be revised, improved to get to the electrical power equivalent state?
Ramblings on Peer Collaborations September 27, 2015Posted by Edwin Ritter in Project Management.
Tags: agile, collaboration, peer, peer programming
add a comment
If you had the choice to work alongside someone or work alone, which would prefer? I know, the default answer is “it depends”. What if your experience was more agile team based or some collaborative approach with peers rather than working alone? What your answer be different?
In the increasingly Agile world, peer collaboration to deliver specific tasks will become more popular going forward. With one person being the driver that focuses on the tactics, the observer or navigator can focus on the big picture and strategic aspects.
This approach not only applies to programming – it can be used in multiple parts of the organization. Examples include : finance, purchasing, engineering, sales and project management.
A brief overview of the Pair Programming technique includes:
- Start with a reasonably well-defined task before you sit down. A key part of the process is to get common understanding of current state and what the impact is with the task you will be working on. I also submit this includes support and debug (in whatever form that is) responsibilities after delivery.
- Agree on one tiny goal at a time Keep it simple – Define the approach, ensure you understand the task. This can be a visual of the workflow, a verbal review of the steps and/or a formal write up posted to a common repository. Agree on the best mechanism that works best with your partner and you to complete your goal. As you define the goal(s), you will find that you will…
- Rely on your partner, support your partner. A major benefit in this approach is to tap into your partners’ expertise. Also, your experience and expertise can compliment your partner.Stay committed and focused on the task at hand. When you have a partner with different skills, here is where working together pays off. Together, you both are smarter than when working alone. Use that to your advantage to define a solution and improve it when you….
- Talk a lot! Think out loud and often. In the early stages, you need to get the ‘creative juices’ going. Bouncing ideas off each other helps to sort out what is and is not feasible to solve the task at hand.
- Sync up frequently. Avoid dominating the conversation and direction. Get feedback, ask questions and confirm you both have a common understanding. Work both the tactical and strategic levels and ensure agreement.
- Take a moment to celebrate as you complete tasks and overcome problems. Victories are always short lived – All too often, being successful gets overlooked. Take a moment to bask in the glow of your accomplishments. You probably learned a bit about yourself and your collaborator as well. Feel better? Good. Now, get back at it!
- Switch roles often—at least every half hour. Related to the driver and observer. As a guideline, switching on that interval may or may not be possible. Define a reasonable interval works for you both and then adhere to it. This may take some time initially to sort what works best. It may also impact office hours and the time commitment you both are willing to make for this effort.
I have use this approach with success in the past working with peer project managers. I understand the hesitation by management to use this approach and to be successful. Collaborating requires a higher level of trust and commitment up and across the organization. By definition, collaborating is a more social way of working that combines strengths and can reduce development cycles. The result is a better work product with fewer defects and delivered in a shorter time.
There are many sites that provide details on this agile technique. Here are a few references to get more background :
Comments invited. Are you comfortable working alongside someone? Would your management support this agile approach?
Ramblings on Release Management August 30, 2015Posted by Edwin Ritter in Project Management.
Tags: release management, release management process, software configuration management, software development, software development lifecycle
add a comment
From a recent project, one of the lessons I learned concerns release management and who drives that process. What I find most interesting is the developers’ view that once code is checked in, the deliverable is complete. I have worked organizations that use a formal software configuration management and release management process (SCM/RM). That role can be a fully staffed position working with development teams to get code changes tested and released.
Related to this topic is environment management and configuration, the related tools and workflow to keep the organization working on the right things and at the right time. Ultimately, the changes are provided for use by external customers to meet their business needs. Let’s not forget that customers keeps the business going.
The SCM/RM process can easily be used with change control to manage the code base consistently. When the SCM/RM is not the responsibility of any single person, I submit that the developer shepherd their respective code changes through the test and release cycles. What I find lacking is ownership from developers on following that through to getting code changes released.
While my expectations are influenced by past experience, I am aware that it is naive to expect other team members will have a level of ownership and commitment consistent with mine.
So the next time there is a change, I will use my greater understanding on what is needed to keep things moving and align my expectations. A lesson learned and one that I am willing to share with others.
Comments invited on the level of effort and ownership with release management. Who drives changes through to release? Is it automated in your shop? What tools and process do you use to manage the code base?
Multitasking is a myth June 16, 2015Posted by Edwin Ritter in career, Project Management.
Tags: Cognitive neuroscientists, decision, multitask, multitasking, priority
add a comment
All employers want it and every employee attests they can do it. Cognitive neuroscientists will tell you that multitasking is not possible. A myth, popular misconception and a white lie employers and employees accept while knowing it is a fallacy. In fact, studies reveal that only 2% of people can effectively multitask.
I understand how multitasking is a desirable trait to have. But, the reality is very few have this ability. Studies also have proved that you are less effective doing multiple tasks versus being singly focused. So, let’s agree to ban multitask as a phrase from job descriptions and be realistic about how to get work done. Having the ability to work on many things in different phases is not multitasking. It is just that – working on many things concurrently. Being able to prioritize is a highly desirable skill to make effective decisions. Maybe that is the better term – prioritization.
Recently, I read about how the mind works and how we organize information. Turns out that we have a system for what grabs our attention. We process information using an attentional system and it has four parts.
1) Default mode – fluid and non-linear thinking (let the mind wander). This is the default mode when the brain is resting. Leads to the creative state. In this mode, thoughts are inward to desires, feelings, planning, daydreaming. While in this mode, we feel refreshed after a nap or vacation.
2) Central Executive mode – stay on task; focused. This is the other dominant mode for attention. Opposite of the default mode; they are yin-yang and exclusive. When one mode is active, the other is not. Writing reports, problem solving, painting are examples while in this mode.
3) Insula – is the ‘switch’ between the default and central executive. Enables shift from one mode to another. A neural switchboard. If the brain switches too often it can lead to dizziness with information overload as a result.
4) Attention Filter – What grabs our attention and causes a change in focus from what is in the sub-concious.
Our brains have a finite capacity to process information. We can keep about 4-6 things in mind at once. Keeping track of too many things requires switching and leads to fatigue. All that switching takes energy, can cause information overload and leads to mistakes or otherwise being unproductive.
Along with information overload, our attention filter has a blind spot. Things that we need to pay attention to; details that impact our decisions can be easily missed. A famous example of the blind spot and selection attention involves a group of people passing a basketball. Clink on the link and watch the selective attention video if you have not seen it before. I’ll wait. See what I mean?
This is formally known as Attentional Resource Theory. When we are focused on a specific thing, it uses most, if not all or our ability to process information. Cognitive studies prove the theory and explain why performance is hampered when multitasking.
We know the brain is a very complex instrument. We continue to learn how it works and these new learnings on how we manage information and make decisions will shape how work is organized, performed and how productive (see post on Capacity & spinning plates) any single person can be.
I admit to not being a multitasker. Not part of the 2% who can. But, I am good at setting and keeping priority to make decisions and I know my capacity.
What techniques do you use to manage your workload? Comments invited, as always.
Gate Review Ramblings May 29, 2015Posted by Edwin Ritter in Project Management.
Tags: gate review, milestone, project, project deliverables, project management office
add a comment
So, one of the projects you are involved with is under way and soon you need to provide an update to the gatekeepers. You know, those people who approved the project and now want to know what’s going on. Depending on the tools and process used, getting a formal project update together can be a formidable task. Projects can change daily so getting the most up to date on status, issues and path forward can be time consuming.
I have found that using a consistent format to provide project updates works best. The gatekeepers know that format and also when to expect updates. I have heard that many project managers don’t like gate reviews. I enjoy them and look forward to meeting with the decision makers who have a vested interest in the project. Getting them in the same room and having one conversation about the project is great. Summarizing the good, the bad and path forward is key.
Regular updates on projects as it progress through each phase is a good thing. Planing for the milestone reviews helps keep the team and the sponsors in sync on where the project is. As part of the gate preparation, I review the updates with my team prior to a gate review. That way, they are aware of what is being said and can revise/improve as needed. Also, getting them in sync with recommendation(s) is also key. Last, the team knows what is the path forward and where are we in the journey to deliver the project.
Some of the lessons learned I found from gate reviews include:
- Be honest – provide the facts, do not gloss over things. Provide the good, the bad and the ugly. Most managers know what is going on in the area of expertise anyway so confirming what they know is a good thing.
- Be clear – summarize progress, current status and recommend path forward. Use a stoplight chart or milestone summary to indicate what is done, what is left and what is next.
- Be candid – ask for help where you need it. By being proactive and committed to success, you are indicating what is needed to keep a project on schedule. Assistance can take many forms and can include resources, applications, training and funding.
Each organization executes the phase and gate process differently. Using a stop light chart is great to visually show the project health. It also provides a way to review the top issues and how to resolve them. Getting everyone on board with what, how and who is one of the best outcomes of a gate review. The best is a pass of course and moving on to the next phase.
At each gate review, there are basically three recommendations:
1) Pass – all deliverables are done for the current phase and the project is ready to move forward.
2) Fail – major issues are unresolved and need to addressed to move forward. Regroup when the issues are completed and ready to pass the gate.
3) Shut down the project. Not used as often as the first two recommendations. However, a viable and valuable recommendation when using the process correctly. This recommendation provides a way to show when a project will not succeed, does not have positive ROI and/or does not satisfy the requirements assigned to the project.
When there are multiple projects in a portfolio, using the stop light chart condenses the project health clearly and provides a great visual of how each project is progressing. Typically, the project management office collects and manages this information on all projects.
Use gate reviews to your advantage. Ask for help where you need it, stay on track and report progress at the next gate milestone.
A project is more than a schedule April 26, 2015Posted by Edwin Ritter in Project Management.
Tags: manage, project, project management, schedule
add a comment
There are many things involved to run a project. Documentation, people, time and money are always involved. As data sources, they are used to develop a project schedule. To manage the tools and processes, a project manager needs skills. Hard skills, soft skills, people skills and technical skills are a few.
As a PM, one of the simplest questions asked is “What’s the schedule say?” A good schedule provides the data on what’s done, what is being worked on and what’s left to do. The schedule easily answers the question “Where are we?” Variations of this include “Are we there yet?” or “What’s next*?” and “How much longer?”
*A favorite of mine, especially when asked by someone on the team. Shows commitment, dedication and confidence on their part. Always good to have those people on a project team.
At times, I have seen an over-reliance on the answer of what the schedule ‘says’ by a manager or customer. Heresy, I know. Don’t get me wrong. I am all for planning, scheduling and getting tasks assigned to dates. But a project is more than a schedule.
The schedule is one part of the project. It shows where you’ve been, where you are and where you are going. Other parts of the include budget, resource allocation and responsibility. Combine those with the assumptions, risks and choices made that then result in a project.
When someone asks “Well, what does the schedule say?”, it says to me that they don’t agree with what they heard. Expectations are not met and something must be wrong with the schedule. When, not if, a PM is then asked “What is wrong with the schedule?”, the answer(s) should be “Here’s what is wrong with the project that results in this schedule.”
There are ways to find out why a project is not aligned with the schedule. From a previous post, here are six signals to review.
What’s your take? Comments invited, as always.
The Level of Math in Risk Management March 28, 2015Posted by Edwin Ritter in Project Management.
Tags: decision matrix, decision process, decision theory, known unknown, risk, risk management, uncertainty, unknown unknown
add a comment
Managing risk and selecting the best mitigation choice can be hard. There are many factors that will influence what choice is selected. Using data to manage risks and assess choices is always good. Having a process to use that data to evaluate choices is better. Having good data to assess risks and a process to determine choices is the point of this post.
Some background first. Decision theory is a complicated subject and is used in many different fields in business and leisure (i.e. – games). There are 4 basic elements in decision theory: acts, events, outcomes, and payoffs. A formal definition is “the mathematical study of strategies for optimal decision-making between options involving different risks or expectations of gain or loss depending on the outcome.” An informal definition of decision theory could be “identifying the values, uncertainties and other issues relevant in a given decision, its rationality, and the resulting optimal decision.”
Got that? Good. Sorting out between what is known and unknown can assist in which risk mitigation choice is best. It is always preferable to be in the magic quadrant and deal with knowns rather than unknowns. Consider these groups in a matrix:
- Known Known – circumstances or outcomes that are known to be possible, it is known that they will be realized with some probability.
- Known Unknown – circumstances or outcomes that are known to be possible, but it is unknown whether or not they will be realized. This is known as a Risk.
- Unknown Known – circumstances or outcome a modeler intentionally refuse to acknowledge that he/she knows.
- Unknown Unknown – circumstances or outcomes that were not conceived of by an observer at a given point in time. This is known as an uncertainty.
In short, those things we know we don’t know are risks and those things we don’t know what we don’t know are uncertainties. In the magic quadrant, both are below the line.
Still with me? The uncertainties, the unknown unknowns, are the hardest pieces to deal with. With decision theory, assigning values of probabilities helps determine which choice is best. As an example, consider the following image. Getting the data to assign the options and organizing into a concise arrangement is where the math comes in.
Not all risks require this level of math and analysis to determine the best mitigation choice. The level of math should be appropriate to the complexity of the project and the potential risks involved. It is worth noting that the difference between an issue and a risk is :
– an issue is something that has occurred which impacts* the project.
– a risk is something that may or may not occur that can impact the project.
* impact can be positive or negative.
I prefer to stay above the line and deal with knowns and those risks that are relatively small on my projects. It makes for simple math and for projects where my preferences matter, I find those are the best projects to manage.
Glad I did not lose you and you got this far. How do you manage risks? What is the level of math required for risks? Simple? Complex? Hybrid? Comments invited.
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.
Ramblings on RACI Matrix for Projects September 25, 2014Posted by Edwin Ritter in Project Management.
Tags: ITIL, matrix, project management, project manager, RACI, RACI matrix, six sigma
A lot of things need to occur to get a project started. For the project manager, understanding the basics about the project – the goal, timing, budget are some of the tasks to getting organized. Included in that understanding is who will do what tasks for the project.
A great way to get organized and develop that overall understanding about the make up of a project is to document. No, really, it is. There are several basic documents that come to mind. As separate and distinct files, those include the scope, charter, schedule and raci matrix. Each of these is important for upfront planning and also during execution of the project. I have found that writing or contributing to each of these is very helpful. Being able to communicate the knowledge of the what, how and who during a project kick-off meeting helps get the team up to speed quickly. Most of the documents are easy to understand conceptually by their title. The last one, the responsibility matrix thing, might be a bit unclear.
Essentially, the raci matrix lists who is responsible for what on a project. As an acronym, it stands for Responsible, Accountable, Consulted and Informed. A brief definition of each will assist in why this document is useful for the project manager, the team and stakeholders.
Responsible – Those who do the work to achieve a task. There is typically one role with a participation type of Responsible.
Accountable – Those who are ultimately accountable for the correct and thorough completion of the deliverable or task, and the one to whom Responsible is accountable. Typically, the Process Owner is Accountable for a process, and there must be only one Accountable specified for each task or deliverable.
Consulted – Those who are not directly involved in a process but provide inputs and whose opinions are sought.
Informed – Those who receive outputs from a process or are kept up-to-date on progress, often only on completion of the task or deliverable.
There is a variation that includes another role for support. There are templates available for a RASCI as well. The ‘s’ stands for support and the definition is :
Support – Resources allocated to Responsible. Unlike Consulted, who may provide input to the task, Support will assist in completing the task.
The RACI matrix is not only used in project management. It is used in other IT processes and methodologies. The RACI matrix is part of the ITIL process for service design and driving service improvement. For Six Sigma methodology, the RACI matrix reflects the basic principles of the process.
Having a RACI helps everyone understand the specific interactions and dependencies involved with the who and what on a project. The RACI matrix is useful for communicating across the organization when a project needs support. This can be very useful in matrixed organizations and reduce the overall time required to get resources.
On this sample, you can see the project manager is accountable for almost everything. Additionally, you can see what each person on the team owns and will drive to completion. A subtle point here in that it also indicates what tasks each person should plan, be involved with for, or otherwise be aware of. From my experience, it also visually emphasizes teamwork and that a team effort is required to deliver the project. Note – the astute among you will notice that the example matrixes shown in this post are transposed. However they are oriented, the concept remains the same.
Comments invited on this tool in project management, ITIL or Six Sigma.
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