Sometimes we can come up with new, and effective approaches to problems by borrowing from seemingly unrelated fields. As an example, I recently had a conversation with a sale training professional that applies the precise art of engineering to empower sales people. This is an attempt to remove the “mystery” part out of sales, and introduce some science, and precision into the sales processes. Before moving to the Coaching industry about 4 years ago, I had a long career history in IT (Information Technology), and the last part of my IT career was in technology development. In my first few months of career coaching, I leveraged best practices I had learned pulling from Leadership coaching, and also the Wieser Coaching method I was trainer in. I relied on these proven methodologies in the early stages of building my career coaching practice. As months went by, realizing I could create some new processes to better help my clients, I started to see some parallels in the work I was doing, and processes I had seen in the field of technology, and software development. Both coaching and software development are complex undertakings. And in both fields sequence is important. Foundational steps are built in early in the overall process, and support later steps that deliver on goals, and refine the deliverables. The more I thought about these similarities I began to understand the parallels are more then superficial, and a new coaching methodology could be built pulling from the best of proven coaching practices, and integrating the core steps I saw in successful technology development. I formalized the phases of the new coaching methodology, and the result is the ASCEND COACHING METHOD. What follows are some high points that I saw in my over twelve years working software/technology development that ultimately became part of the ASCEND COACHING method.
Once the software client brings forth a vision of what they see for a technology solution, usually the first real phase that involves technology resources are formalized interviews. In short, designated people from the IT Team ask questions of the project sponsor to better understand the needs of the client, and to remove any ambiguity from the client’s requirements. Sometimes projects fail in various ways because the right questions are not asked. A big lesson I learned when involved in the requirements phase of a project, is that IT needs to ask the right questions. Otherwise the project moves forward, but ultimately the results are not what the client wanted, or expected. But assuming the requirements phase is managed properly, the next step that normally happens is some kind of assessment. This assessment is typically handled by solution, application, or sourcing architects, but can also be handled by development leads, or even business analysts in the early stages. The assessment is to understand the technology gaps, and impact of the project. A technical person reviews the client needs, and maps those needs against current software, and systems. They then create a high-level design to call out what systems will be impacted, and give some estimate of how much effort will be needed to deliver the client’s technology/software needs. To summarize, first we ask questions, and then we do an assessment based on current state, and client’s needs.
Once assessment is completed, there is usually some discussion of targets, or “goals”. Since resources, in both money, and talent, are always limited, there may be a prioritization of technology deliverables falling under the project. There are usually some decisions made on whether some deliverables, or goals are realistic, and should remain in the project going forward, or taken “out of scope”. If some needs are urgent, with low to moderate IT effort involved, those tend to stay in scope. There is also some discussion between the technology client, and the development team with regards to deadlines. When can the first pieces be delivered? Will the overall project be split into multiple phases with some deliverables being delivered at different times? These are questions that are usually discussed at a high level as the client sponsor, and the IT teams agree on reasonable goals.
With assessments and goals set, a next critical phase of a project takes shape, and a detailed plan is formalized. The purpose of the plan is to describe HOW the IT teams will deliver the software, and technology requested by the client, and WHEN the technology will be delivered to the client sponsor. It is also typical to see what resources will be engaged in the project, and what they will be responsible for. In short, accountability is clearly laid out as part of the project plan. At a high level, the plan is about “how do we get from current state to deliver on the stated goals, and in what time-frame.”
After the project plan is approved and funded the work of building the solution begins. In software projects this means that developers begin their coding, and other development activities. But it can also mean that third party products are acquired, and vendors are engaged to deliver their pieces that support the project solutions. It can also mean that quality assurance testers begin writing test scripts to ensure that the final software delivers on what was promised in the scope of the project. Part of the execution of the plan are frequent touch-points to monitor progress, and identify any blocks or bottlenecks to the project work.
During the build phase of a project there is ongoing tracking, and consideration of next steps. Some of these next steps follow the expected processes that are contained in the project plan. But they can also be next steps, or next tasks related to gaps that are identified during the build phase. The goal is to close the gaps and keep the project, and work on track. When managed successfully, the project moves forward and true to timelines that are specified in the plan.
A final phase in software, and technology projects is the delivery of the solution into production. This is when new software, or enhancements to existing software, and systems are rolled out into production. The users can begin leveraging the new functionalities, and features. If the project had solid requirements, a skillful architecture, development, and testing the project sponsors enjoy the work of many teams in the realization of a solution that will better support their business processes.
After working in the coaching industry for several years, I began to see that some of the phases of software development methodology I had seen could be reframed, and utilized in coaching! The bare bones of the method could be around asking of questions, and an assessment, followed by capturing of goals, then creation of a plan, and execution of tasks, or the build phase. During the build phase, there is tracking of progress, and if there are obstacles or bottlenecks the next steps are considered. The final phase is the delivery on the solution, or put another way, delivery of the goals. These seven phases became the foundations of the ASCEND COACHING METHOD. A coaching methodology that strives to understand the vision of the Client, assess the Client’s current state, create and execute an action plan, and ultimately deliver on the Client’s goals. The method puts the Client’s needs first, and puts the coach in a responder role, working to satisfy the Client’s vision, and agenda. In short, the method’s aim is empowerment of the Client.
AUTHOR: Brian Kail, MBA. CPC is a Professional Career, and Executive Coach
Once the software client brings forth a vision of what they see for a technology solution, usually the first real phase that involves technology resources are formalized interviews. In short, designated people from the IT Team ask questions of the project sponsor to better understand the needs of the client, and to remove any ambiguity from the client’s requirements. Sometimes projects fail in various ways because the right questions are not asked. A big lesson I learned when involved in the requirements phase of a project, is that IT needs to ask the right questions. Otherwise the project moves forward, but ultimately the results are not what the client wanted, or expected. But assuming the requirements phase is managed properly, the next step that normally happens is some kind of assessment. This assessment is typically handled by solution, application, or sourcing architects, but can also be handled by development leads, or even business analysts in the early stages. The assessment is to understand the technology gaps, and impact of the project. A technical person reviews the client needs, and maps those needs against current software, and systems. They then create a high-level design to call out what systems will be impacted, and give some estimate of how much effort will be needed to deliver the client’s technology/software needs. To summarize, first we ask questions, and then we do an assessment based on current state, and client’s needs.
Once assessment is completed, there is usually some discussion of targets, or “goals”. Since resources, in both money, and talent, are always limited, there may be a prioritization of technology deliverables falling under the project. There are usually some decisions made on whether some deliverables, or goals are realistic, and should remain in the project going forward, or taken “out of scope”. If some needs are urgent, with low to moderate IT effort involved, those tend to stay in scope. There is also some discussion between the technology client, and the development team with regards to deadlines. When can the first pieces be delivered? Will the overall project be split into multiple phases with some deliverables being delivered at different times? These are questions that are usually discussed at a high level as the client sponsor, and the IT teams agree on reasonable goals.
With assessments and goals set, a next critical phase of a project takes shape, and a detailed plan is formalized. The purpose of the plan is to describe HOW the IT teams will deliver the software, and technology requested by the client, and WHEN the technology will be delivered to the client sponsor. It is also typical to see what resources will be engaged in the project, and what they will be responsible for. In short, accountability is clearly laid out as part of the project plan. At a high level, the plan is about “how do we get from current state to deliver on the stated goals, and in what time-frame.”
After the project plan is approved and funded the work of building the solution begins. In software projects this means that developers begin their coding, and other development activities. But it can also mean that third party products are acquired, and vendors are engaged to deliver their pieces that support the project solutions. It can also mean that quality assurance testers begin writing test scripts to ensure that the final software delivers on what was promised in the scope of the project. Part of the execution of the plan are frequent touch-points to monitor progress, and identify any blocks or bottlenecks to the project work.
During the build phase of a project there is ongoing tracking, and consideration of next steps. Some of these next steps follow the expected processes that are contained in the project plan. But they can also be next steps, or next tasks related to gaps that are identified during the build phase. The goal is to close the gaps and keep the project, and work on track. When managed successfully, the project moves forward and true to timelines that are specified in the plan.
A final phase in software, and technology projects is the delivery of the solution into production. This is when new software, or enhancements to existing software, and systems are rolled out into production. The users can begin leveraging the new functionalities, and features. If the project had solid requirements, a skillful architecture, development, and testing the project sponsors enjoy the work of many teams in the realization of a solution that will better support their business processes.
After working in the coaching industry for several years, I began to see that some of the phases of software development methodology I had seen could be reframed, and utilized in coaching! The bare bones of the method could be around asking of questions, and an assessment, followed by capturing of goals, then creation of a plan, and execution of tasks, or the build phase. During the build phase, there is tracking of progress, and if there are obstacles or bottlenecks the next steps are considered. The final phase is the delivery on the solution, or put another way, delivery of the goals. These seven phases became the foundations of the ASCEND COACHING METHOD. A coaching methodology that strives to understand the vision of the Client, assess the Client’s current state, create and execute an action plan, and ultimately deliver on the Client’s goals. The method puts the Client’s needs first, and puts the coach in a responder role, working to satisfy the Client’s vision, and agenda. In short, the method’s aim is empowerment of the Client.
AUTHOR: Brian Kail, MBA. CPC is a Professional Career, and Executive Coach
RSS Feed