Listen in to learn more about how to engage your business and support your development teams with deeper insight into the function of Quality Assurance with guest Christopher Scharer, in today's podcast.
Christopher holds deep experience in software development and automated software testing, working in the field since 1980. With experience in data-driven, keyword-driven and hybrid methodologies, Christopher has helped companies achieve testing success in a wide variety of business applications in the banking, finance, & healthcare industries.
In our conversation we define in clear terms what the expected function of QA (Quality Assurance) within the Software Development LifeCycle (SDLC) is, contrast that against Quality Control, and look at implication of different development methodologies and the application of QA.
At a higher level, we also explore how to engage your IT function and business units in the support of developing QA skills or functions, discuss the merits of in-sourcing and out-sourcing QA, and discuss the most important skills and traits to seek out or develop for Quality Assurance professionals in today's IT marketplace.
All of this in 30 minutes of engaging conversation that will appeal to any IT or business professional.
Click the link below to download the audio for this podcast.
itManageCast Episode 5 - The Quality Assurance Consultation
For feedback on this or any episode of the itManageCast podcast, or to recommend topics or guests for future shows, please contact us via Twitter @itManageCast or email us at our GMail account.
Links:
To contact Christopher Scharer directly please email: Christopher.Scharer@Vivit-Worldwide.org
Monday, March 2, 2015
Monday, February 16, 2015
Podcast Episode 4 - The Disaster Recovery Discussion
In episode 4 of the itManageCast podcast, Tom Wahl joins host Jason Kennedy to provide insight into Disaster Recovery and Business Continuity planning for the IT professional.
In this 30 minute conversation Tom and Jason explore the essential aspects of disaster recovery and business continuity, where they are the same and where they are different.
We also discuss where the IT professionals responsibility for these services should ideally begin and end, and how to engage the other business functions in your organization into ownership over them.
Last but not least, Tom provides some insight into where to start if you are tasked with providing a disaster recovery plan for your organization.
Click the link below to download the audio for this podcast.
itManageCast Episode 4 - The Disaster Recovery Discussion
For feedback on this or any episode of the itManageCast podcast, or to recommend topics or guests for future shows, please contact us via Twitter @itManageCast or email us at our GMail account.
Links:
to contact Tom Wahl directly email: tom@twltd.com
Thursday, February 5, 2015
Podcast Episode 3 - The IT Service Transformation Talk
We discuss in depth what it is, what it isn't, and how to ensure successful outcomes.
Gilles provides some insight into how to gain business sponsor support for IT Service Transformation activities, and how to leverage these principles to improve the efficiency of your IT operations.
Click the link below to download the audio of the podcast:
itManageCast Episode 3 - The IT Service Transformation Talk
To watch the video recording of the podcast on YouTube, click Podcast here or at the top of this page.For feedback on this or any episode of the itManageCast podcast, or to recommend topics or guests for future shows, please contact us via Twitter @itManageCast or email us at our GMail account.
Links:
- email: gmarconsulting@outlook.com
- itSMF Canada
- Project Management Institute
Wednesday, January 28, 2015
Podcast Episode 2 - The Database Conversion Conversation
In our second episode Chris Umphenour of Life Center Ministries joins host Jason Kennedy to discuss lessons learned from a database conversion project in a small to mid-sized IT shop.
Chris shares his experiences regarding planning and shares advice on how to ensure you are set up for success if you need to undertake a database conversion project under time and budget constraints. We also enumerate the key roles and responsibilities needed within the project team to see success.
Click the link below to download the audio of the podcast:
itManageCast Episode 2 - The Database Conversion Conversation
To watch the video recording of the podcast on YouTube, click Podcast here or at the top of this page.
For feedback on this or any episode of the itManageCast podcast, or to recommend topics or guests for future shows, please contact us via Twitter @itManageCast or email us at our GMail account.
Tuesday, January 20, 2015
Know Thyself to Recover from Demotivation
In many activities, and most certainly in the process of a job search, it is common and expected to hit valleys of enthusiasm, or feel de-motivated.
The human psyche constantly moves through cycles of energy or enthusiasm for any activity we undertake - our work, exercise, chores about the home. Quite frankly, we will not be able to pro-actively "level out" these peaks and valleys nor should we.
What we need to do is understand what emotions and experiences are driving those highs and lows so that we can respond to them in a self-constructive manner.
A fascinating "big data social media" study released by social sciences researchers in 2011 noted that regardless of where you live and what you do, your enthusiasm - your motivation level - is going to naturally cycle through the day, week, month, and year.
The science behind this is explained in a variety of articles and studies and to sum it up, it's normal - there's nothing "wrong" with feeling un- or de-motivated at times. What that signals is that there is an underlying cause for the feeling that requires your response in a timely manner.
Ask yourself why?
So key to addressing lows or "dips" in your motivation is understanding why you are feeling that way. This can be complicated, and sometimes a bit scary. And let's be frank, I'm not a psychologist or spiritual advisor, I just play one on TV.
However, to share with you what I've learned through my current process of job transition is that it can often be easier to catch up on missed episodes of your favourite show on Netflix rather than knuckle down to the job search, but if you get at the root cause you will get re-energized and move forward with increased enthusiasm that shows through to everyone you meet.
Taking on new challenges can be exciting and invigorating at first - the motivational peak. But once under-way, the risks or concerns - what might go wrong - start to creep up, and your motivation can (and usually will) slump. Planning ahead for those slumps will help you move through them with minimal impact, and keep you moving forward.
"Plan...and use slow-down periods to re-energize..."
Expect that you are going to hit some lows, some lack of motivation. Plan some time during the motivational peaks to assess what the motivating factors are, and consider the risks that you might find demotivating - then plan, and use those slow-down periods to re-energize, focus, and move yourself forward.
Human emotions - generally - follow the "universal rules" of cause and effect. Take pause to consider the cause and you can affect the effect.
The human psyche constantly moves through cycles of energy or enthusiasm for any activity we undertake - our work, exercise, chores about the home. Quite frankly, we will not be able to pro-actively "level out" these peaks and valleys nor should we.
What we need to do is understand what emotions and experiences are driving those highs and lows so that we can respond to them in a self-constructive manner.
A fascinating "big data social media" study released by social sciences researchers in 2011 noted that regardless of where you live and what you do, your enthusiasm - your motivation level - is going to naturally cycle through the day, week, month, and year.
The science behind this is explained in a variety of articles and studies and to sum it up, it's normal - there's nothing "wrong" with feeling un- or de-motivated at times. What that signals is that there is an underlying cause for the feeling that requires your response in a timely manner.
Ask yourself why?
So key to addressing lows or "dips" in your motivation is understanding why you are feeling that way. This can be complicated, and sometimes a bit scary. And let's be frank, I'm not a psychologist or spiritual advisor, I just play one on TV.
However, to share with you what I've learned through my current process of job transition is that it can often be easier to catch up on missed episodes of your favourite show on Netflix rather than knuckle down to the job search, but if you get at the root cause you will get re-energized and move forward with increased enthusiasm that shows through to everyone you meet.
Taking on new challenges can be exciting and invigorating at first - the motivational peak. But once under-way, the risks or concerns - what might go wrong - start to creep up, and your motivation can (and usually will) slump. Planning ahead for those slumps will help you move through them with minimal impact, and keep you moving forward.
"Plan...and use slow-down periods to re-energize..."
Expect that you are going to hit some lows, some lack of motivation. Plan some time during the motivational peaks to assess what the motivating factors are, and consider the risks that you might find demotivating - then plan, and use those slow-down periods to re-energize, focus, and move yourself forward.
Human emotions - generally - follow the "universal rules" of cause and effect. Take pause to consider the cause and you can affect the effect.
Wednesday, December 17, 2014
Cloud ReMix - How Personal Use Can Influence Business Decisions
Most of us spend a lot of time reading and thinking about cloud services for business use, and learning ways to ensure we make the best use of these types of services to benefit our business. Gaining the most efficiency, lowest cost, and least risk.
These are all valuable considerations, and important to be focussing on when making any cloud-based investment in IT services. But what framework do we use use to make these evaluations?
I was recently contacted by a cloud services company called SingleHop and they wanted to share an infographic they had designed.

The correspondence I had with Dave from SingleHop prompted me to think about leveraging ways I use the cloud in my day to day life to form the criteria used to evaluate cloud services for business use.
Further to that thought, is the consideration of how we IT professionals can communicate more effectively with other business professionals when we want them to understand how business services are enabled by cloud-based IT services.
By leveraging their every-day cloud experiences all of a sudden the mysterious world of business IT services in the cloud become much less "mystical."
What do you personally use the cloud for every day, or each week? I use it for storage of photos and video, collaboration & productivity with partners on various projects, and email. The fact is, Google holds the lion's share of my personal cloud-based activity and why? Because it's convenient, reliable, and inexpensive.
If you think about it, that reflects back on key cloud-service metrics such as agility, quality of service, and economics. And in thinking about how we value these metrics in our personal use of cloud-based services, we can frame ways to better communicate those metrics with others who don't live in the IT world.
So take a quick look at the graphic from SingleHop, and think about how you can influence business decisions about cloud-based business services based on more familiar personal interactions with the cloud.
And thanks Dave for sharing the graphic. Nice work.
These are all valuable considerations, and important to be focussing on when making any cloud-based investment in IT services. But what framework do we use use to make these evaluations?
I was recently contacted by a cloud services company called SingleHop and they wanted to share an infographic they had designed.

The correspondence I had with Dave from SingleHop prompted me to think about leveraging ways I use the cloud in my day to day life to form the criteria used to evaluate cloud services for business use.
...leveraging every-day cloud experiences (makes the) world of business IT services in the cloud ... much less "mystical."
Further to that thought, is the consideration of how we IT professionals can communicate more effectively with other business professionals when we want them to understand how business services are enabled by cloud-based IT services.
By leveraging their every-day cloud experiences all of a sudden the mysterious world of business IT services in the cloud become much less "mystical."
What do you personally use the cloud for every day, or each week? I use it for storage of photos and video, collaboration & productivity with partners on various projects, and email. The fact is, Google holds the lion's share of my personal cloud-based activity and why? Because it's convenient, reliable, and inexpensive.
If you think about it, that reflects back on key cloud-service metrics such as agility, quality of service, and economics. And in thinking about how we value these metrics in our personal use of cloud-based services, we can frame ways to better communicate those metrics with others who don't live in the IT world.
So take a quick look at the graphic from SingleHop, and think about how you can influence business decisions about cloud-based business services based on more familiar personal interactions with the cloud.
And thanks Dave for sharing the graphic. Nice work.
Wednesday, December 10, 2014
Three Quick Tips That Will Save an IT Project Manager's Reputation
You're a great IT project manager. You know it, and more others should. But for some reason, you struggle with the hand-over part at the tail end of the project. The infamous "Transition to Operations."
You have all the deliverables completed & signed off, but the new service just seems to struggle and flail like a fish that just hopped out of the bowl and onto your desk. And while you may have moved on to the next project, the business service owners fighting with the last implementation are now muttering under their breath.
How can this be avoided?
One sure fire way is to be thinking of the "transition to operations" from the outset of the project planning & chartering. And think about how this service will be supported and operated daily by the people who will be responsible for it, and the people who will be using it. Likely, you've already got those considerations on your check-list, and that's great.
But are you making sure that the operational & support documentation delivered through the project reflects this?
Here are, for your consideration and feedback, three simple ideas to ensure that the documentation to support the hand-over of the completed project are both useful, and used!
One of the most common concerns a PM will hear from the IT subject matter experts - the technicians, analysts, or engineers on their project team - is that they only have enough time to do the work, not write a story about what they've done.
It is your responsibility as the PM that your project plan and task lists (work breakdown structure. etc) include ample time and clear expectations that any system configurations, support procedures, or operational maintenance tasks are documented clearly.
Communicate this expectation clearly, early, and often. But it won't be enough to tell the team what to do; you need to empower them to do it.
It's often not going to be enough to tell people what to do. A true leader will lead them; show them what is expected and support them in getting it done.
Have some simple templates available at the outset of the project to share with the technical experts supporting the project delivery. Don't accept "it is self-documenting" as an answer. Ever. It really isn't.
You should review all the support and operational documentation output of the project. You don't necessarily need to understand every nuance, but you DO need to be able to read it and get the gist.
Technical experts are rarely writers by trade or skill. It's just not what they do. They will take short-cuts in their documentation, and rightly so, as they understand it - they built it!
But what happens in four or five years when the service needs an overhaul and that particular person isn't with the organization any longer?
What happens when the project rolls out and a more junior resource is tasked with operating or supporting the technology aspects of the new service?
Consider these scenarios when reviewing the documentation with the technical authors.
And those tips help get the documentation needed by the technical folks completed - but what about the support model for the service?
Be selective in who you involve, and bring them "nearly completed" drafts of the support model to review and contribute to in order to respect their time and keep potential re-writing to a minimum.
Following these simple tips should help others see what a great IT PM you really are.
If you have other tips and tricks for IT Project Management, or feedback on these ideas, please share them with me in the blog comments or via my Twitter account - @itManageCast
Thanks for reading, and have an awesome day!
You have all the deliverables completed & signed off, but the new service just seems to struggle and flail like a fish that just hopped out of the bowl and onto your desk. And while you may have moved on to the next project, the business service owners fighting with the last implementation are now muttering under their breath.
How can this be avoided?
One sure fire way is to be thinking of the "transition to operations" from the outset of the project planning & chartering. And think about how this service will be supported and operated daily by the people who will be responsible for it, and the people who will be using it. Likely, you've already got those considerations on your check-list, and that's great.
But are you making sure that the operational & support documentation delivered through the project reflects this?
Here are, for your consideration and feedback, three simple ideas to ensure that the documentation to support the hand-over of the completed project are both useful, and used!
Build in time for the experts to document their work.
One of the most common concerns a PM will hear from the IT subject matter experts - the technicians, analysts, or engineers on their project team - is that they only have enough time to do the work, not write a story about what they've done.
It is your responsibility as the PM that your project plan and task lists (work breakdown structure. etc) include ample time and clear expectations that any system configurations, support procedures, or operational maintenance tasks are documented clearly.
Communicate this expectation clearly, early, and often. But it won't be enough to tell the team what to do; you need to empower them to do it.
Provide the experts with simple tools to document their work.
It's often not going to be enough to tell people what to do. A true leader will lead them; show them what is expected and support them in getting it done.
Have some simple templates available at the outset of the project to share with the technical experts supporting the project delivery. Don't accept "it is self-documenting" as an answer. Ever. It really isn't.
You should review all the support and operational documentation output of the project. You don't necessarily need to understand every nuance, but you DO need to be able to read it and get the gist.
Technical experts are rarely writers by trade or skill. It's just not what they do. They will take short-cuts in their documentation, and rightly so, as they understand it - they built it!
But what happens in four or five years when the service needs an overhaul and that particular person isn't with the organization any longer?
What happens when the project rolls out and a more junior resource is tasked with operating or supporting the technology aspects of the new service?
Consider these scenarios when reviewing the documentation with the technical authors.
And those tips help get the documentation needed by the technical folks completed - but what about the support model for the service?
Have the end-users of the service contribute to the support model.
The documentation to ensure that the service has a clear model of support, escalation paths, and service expectations should always have input from a small, careful selection of those who will be active end-users of the service once it goes live.Be selective in who you involve, and bring them "nearly completed" drafts of the support model to review and contribute to in order to respect their time and keep potential re-writing to a minimum.
Following these simple tips should help others see what a great IT PM you really are.
If you have other tips and tricks for IT Project Management, or feedback on these ideas, please share them with me in the blog comments or via my Twitter account - @itManageCast
Thanks for reading, and have an awesome day!
Subscribe to:
Posts (Atom)




