tag:blogger.com,1999:blog-52668914844413806622024-03-13T06:02:35.086-04:00Information Technology LeadershipProject Management and technology leadership - plain and simple. Common sense techniques to manage project schedules, improve communications with your project team, manage expectations, improve processes and customer satisfaction. This includes many examples and observations from almost thirty years working in education, manufacturing, and business.Unknownnoreply@blogger.comBlogger46125tag:blogger.com,1999:blog-5266891484441380662.post-52966518496525908482015-08-21T00:23:00.001-04:002018-01-20T10:57:06.726-05:00Consistent Messages<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-V7j2ncvOZYU/VdU3b7IGDkI/AAAAAAAAAGw/McuTrfwihAw/s1600/cemeteary.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="320" src="https://4.bp.blogspot.com/-V7j2ncvOZYU/VdU3b7IGDkI/AAAAAAAAAGw/McuTrfwihAw/s320/cemeteary.jpg" width="292" /></a></div>
<b>When we send mixed messages... we create confusion and chaos.</b>
Which spelling is correct? Close your eyes, and you can probably spell this word correctly. I'll give you a hint, the correct spelling is in the foreground. What's in the background is nothing more than mixed signals that create a confusing message.<br />
<br />
Imagine the impact on a child learning to spell. I am the very proud recipient of a spelling bee trophy from elementary school, and these signs initially confused me. Road signs, like computers, are NEVER wrong!!! Maybe only the white ones are correct, or is the the green?<br />
<br />
I'm going to ask that you reflect... are you sending, and receiving consistent messages? Or, like these signs, are you delivering confusing messages to your team, and receiving mixed signals from above?<br />
<br />
Your mantra should be... manage from where you are, and send consistent messages. Don't be afraid to point out inconsistencies that come from above. Only when there is a clear destination can the journey be efficient, and... well... quite enjoyable. Remove these stresses. As a unit, refine your mission and vision, then refocus your efforts using consistent messages.<br />
<br />
Consistency is critical in life, in parenting, and in your relationships. As my children, all now adults, were growing up, they always quipped that they knew my answer to their questions before the words left their mouth. How? It was through consistency. If we know the parameters and expectations, we are more likely to be successful within those limits. We can stretch the limits as we grow, as long as we communicate, maintain mutual trust, and deliver a consistent message.<br />
<br />
Consistence is a result of <u>words</u> matching your <u>actions</u>. If you want the respect of your peers and your team, be consistent.<br />
<ol>
<li><u>Provide excellent customer service</u><b> - </b>You cannot expect excellent customer service and set high expectations for others, yet not provide others the same level of service.</li>
<li><u>Be responsive</u><b> - </b>You cannot expect your team to be responsive, if you're not responsive.</li>
<li><u>Commit and deliver</u><b> - </b>You cannot commit to deadlines and not deliver, then hold others accountable.</li>
<li><u>Be trustworthy</u><b> - </b>You cannot commit to help others, then not provide the assistance.</li>
<li><u>Be consistent</u><b> - </b>You cannot say one thing, then do another.</li>
<li><u>Roll up your sleeves and help</u><b> - </b>You cannot ask your team to put in extra efforts on a project, and not contribute.</li>
<li><u>Finish what you start</u><b> - </b>You cannot ask your team to be dedicated, if each of your positions are just a stepping stone to your next promotion.</li>
<li><u>Be transparent</u><b> - </b>You cannot ask for transparency, and not provide it.</li>
<li><u>Be inclusive</u><b> - </b>You cannot ask for a say in decision making, and not share it.</li>
<li><u>Climb up on the balcony and look around</u> - you cannot determine your state in life, on a project, or in an organization without taking the time for reflection.</li>
</ol>
<div>
I have worked for companies that have delivered an inconsistent message. I can tell you that this is confusing, and has a huge negative drag on employee morale and motivation. Needless to say, I have tried to provide feedback to improve these environments. If this was unsuccessful, then it was time to find a better cultural fit. Why? Confusion and inaction will fill the void created by a lack of consistency. When there is confusion, there is inconsistency that can transform productive people into zombies that are incapable of making good decisions. People don't lose their job for being safe, they lose their job from taking risks and making poor decisions when there is an inconsistent message.</div>
<div>
<br /></div>
<div>
So, I guess the moral of this post is be consistent, and prevent another zombie outbreak at your organization. Use a consistent message to motivate your team, build morale, and create a sense of community. If you work for a zombie company, you have three choices: undertake the hard work of changing the culture, assume resistance is futile and join the dark side, or exit and head for the light.</div>
<div>
<br /></div>
<div>
It's your move... choose one: action, inaction, or ambivalence. Before you chose, remember that your career is a reflection of your life, and living differently outside of work than inside is asking for internal conflict. So, make a choice, and move forward!</div>
<div>
<br /></div>
<div>
If you want to see the sign in person, it's in Cooks Forest, near Cooksburg, PA.</div>
<div>
<br /></div>
Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5266891484441380662.post-19666307484523884102015-08-09T21:59:00.003-04:002018-01-20T10:57:45.214-05:00Contracts Negotiations...<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-CQyDc9ri8GY/VcgFYF4dLCI/AAAAAAAAAGY/iOeUMtTUK3Y/s1600/contractnegotiations.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="220" src="https://4.bp.blogspot.com/-CQyDc9ri8GY/VcgFYF4dLCI/AAAAAAAAAGY/iOeUMtTUK3Y/s320/contractnegotiations.png" width="320" /></a></div>
<h1>Contract Negotiation Tips.</h1>
The recently proposed Iran agreement has created a significant amount of controversy. Much of the tone and rhetoric has been around the quality of the negotiations, and our ability to audit and enforce agreement compliance. Because of this, I’ve been reflecting on my personal experiences reviewing and negotiating information technology related contracts.
My scenarios are significantly different.<br />
<br />
There are no lives at risk. My involvement has primarily been with software, systems, and communications purchases. My first exposure was at an extremely well managed and efficient nationwide manufacturer. They were a family owned company that challenged everyone to continually improve, and operated in a very lean and efficient manner. This experience provided the base foundation for my own leadership journey.<br />
<br />
<b>The experience had taught me the following:</b><br />
<br />
<b>Negotiate from strength.</b> The Vice President of Purchasing (Mike) always negotiated from strength. When Mike went in to purchase materials or equipment, he knew what he needed from the deal. He was ready to walk away if he didn’t achieve this goal. I’ve heard stories of people asking for his best price, and Mike responding with his number. When they countered the offer, he’d shock them by lowering his price instead of increasing it. That dance would continue until Mike received his terms, or he would walk away from the deal. It sounds like John Kerry never went in with this attitude, or the outcome could have been much different.<br />
<br />
<b>Be prepared to walk away.</b> I was told of one instance in Mike's personal life where he visited a Cub Cadet dealer. Mike asked for the dealer’s best price, and apparently received it. He counter-offered a significantly lower price to start the game. The Cub Cadet salesperson went to his office and sat down at his desk. Mike assumed he was sharpening his pencil. The salesperson never came back outside, and Mike never went back in – both knew what they wanted, and were willing to walk away. If you’re too far apart on what your requirements, don’t be afraid to walk away. If Mike would have went back inside, or the salesperson came back outside, one or the other would have lost their leverage. Were our negotiators willing to use their strength and walk away?<br />
<br />
<b> Set clear expectations.</b> I met with Jim, the company's Executive Vice President to discuss the contract for a large ERP software purchase we were negotiating. We worked closely together with Mike to negotiate the price and terms for all technology purchases. Jim related an experience he had as an executive at a smaller airline. As he was reviewing a purchase of a multi-million dollar jet, and reading the terms and conditions, he made an odd discovery. He realized the aircraft he was purchasing wasn’t guaranteed to fly. He had done his best to improve the terms and conditions. However, this was only effective up to the point where the vendor was willing to walk away. In some cases, there was little he could do since he wasn’t negotiating from a place of power. He needed the airplane to fly passengers and generate revenue. In other situations, he was negotiating from a place of power, and was able to obtain significantly better agreements. The key, he said, was mitigating risk to an acceptable level… understanding what’s critical… and recognizing your leverage. Enter your negotiations process knowing your bottom line price for the level of service you require, each partners responsibilities, and what risks need mitigated before you can accept the agreement. Did our country do this with the treaty?<br />
<br />
<b>Communicate clearly, and get contract clarification in writing.</b> Ambiguous language should not exist in a contract. If there’s something you don’t understand, or that is subject to interpretation… get a concise explanation that both you and your vendor can interpret clearly included as a signed addendum. The tale about the buyer at an auction asking what to do via text when the equipment he wanted was higher than he was authorized to spend is an appropriate example. The authorization he received included “no price too much”, so he kept bidding until he won the auction. Unfortunately, so the story goes… what should have been communicated was “no, price too much” – a very different message. The company ended up going bankrupt because the added equipment expense damaged their ability to continue operations profitably. Make sure you’re communications, interpretations, and understanding with the vendor are mutual and concise. Explicit contracts that clearly outline the contract requirements do not signal mistrust, and are NOT counter to a successful vendor relationships. Quite to the contrary - they reduce misinterpretations, build trust, and become the foundation for a mutually beneficial and profitable partnership.<br />
<br />
<b>Recognize risk and scope appropriately.</b> Read the terms and conditions. Open source software licenses do not require monetary payment. However, some do require any vendor that incorporates this code into their product to also make it freely available under the open source license. This isn’t a good option for a vendor that markets software and makes their money by selling software solutions. Work with your leadership to identify parameters for acceptable risk, and understand these limits. There is a different level of risk purchasing a copy of Microsoft Office vs. negotiating an enterprise software agreement. Did our leadership recognize the risk and scope for the Iran deal?<br />
<br />
<b>Be fair, and partner for success.</b> Your goal with contract negotiations is to create a fair and explicit agreement for all parties involved. There is no success in driving a critical supplier into bankruptcy. This agreement is the basis for a collaborative partnership. There may be times where you may need something expedited, and you'll need goodwill to help get things done that may be outside the scope of the agreement. If every agreement is one-sided, you'll damage any potential relationships, and that won't help your organization in the long run. If you want customer loyalty, then you must have some level of commitment with developing and establishing relationships with your key vendors.
<br />
<br />
<b>Differentiate between critical and non-mission critical agreements.</b> Know what's critical and important for your organization. Based on your industry, the importance of a paper contract could be quite different. Treat each type of agreement appropriately. If you negotiate a paper contract for a widget manufacturer, these are likely considered expenses and probably not part of your core business unless they are required for packaging. The level of diligence may not be as important as ensuring that purchases of widget raw materials meets your requirements and is delivered on time. However, paper would be critical if you're in an industry that requires these as a raw material to deliver goods and services, such as a newspaper printer.<br />
<br />
<b>Be explicit with context. </b>I have one final thought on clarity in communications. Be specific and explicit in negotiations, and ensure you have spelled out the CONTEXT for each of the critical points. Do not assume context, or your contracts will be subject to misinterpretation and miscommunication.<br />
<br />
I thought I’d share some of the my thoughts on contracts review and negotiations. So, don’t be afraid to work hard and get your hands dirty. Always take the time to climb up to the top of the mountain, reflect, and look out on the horizon to survey the landscape. From the mountain top, we can get perspective on our progress, identify threats and opportunities, adjust our processes and direction, and be proactive. Go climb your mountain, survey your landscape, and adjust as appropriate. This journey is easier if you find a great mentor - mine was "Jim". Go find your "Jim"!<br />
<br />
I hope you enjoyed reading this as much as I enjoyed writing this entry.
Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5266891484441380662.post-61311316803836703632015-07-31T00:12:00.002-04:002015-07-31T00:51:40.615-04:00Right-size Processes To Add Value<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-F7j7GXub46Y/Vbr-R5yhuSI/AAAAAAAAAF4/pH9tyfsKHQA/s1600/RightSizeProcess.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img alt="" border="0" height="225" src="http://1.bp.blogspot.com/-F7j7GXub46Y/Vbr-R5yhuSI/AAAAAAAAAF4/pH9tyfsKHQA/s320/RightSizeProcess.png" title="Rightsize for Value" width="320" /></a></div>
I've been in a few conversations recently about "overhead' processes, and my favorite topic - <u>adding value</u>. I'm going to provide a few examples of what I consider <u>rightsizing processes</u>. These processes should be <u>implemented judiciously and appropriately</u> to deliver the information and results needed to <u>add value</u> and deliver your projects on time.<br />
<br />
Often excess processes can significantly reduce productivity, and staff become complacent and don't believe the work they are doing is important. Keep your team energized by being a leader and establishing processes that are appropriate, effective, and add value. Some broad examples of rightsizing are below:<br />
<ol>
<li>Project Management - I cannot stress the importance of tracking projects at an appropriate level to create a critical path for developing and managing the timeline. My experience is that this is as much of an art as a science. The science is in the methodology, the art is in the understanding and ability to identify dependencies and timing accurately.</li>
<li>Time tracking - I've posted about this previously. Track sufficient information using appropriate granularity to support your project schedules, accounting for resource time in a broad sense by service and category. Right size this so you do not expend valuable project and service resources recording unnecessary information. Tracking information that is not useful for improving project management, increasing support for the service, or fulfilling sponsor reporting requirements is frustrating for staff and wastes precious resources.</li>
<li>Disaster Recovery / Business Continuity Planning - Nobody ever expects a disaster to occur. However, they do... and it is too late when you realize that the one person with the knowledge to recover your enterprise service just took off in a plane destined for a remote village half-way around the world. </li>
<li>Cross Training - Cross train your staff, and document basic operational requirements. They may complain about the additional work. However, when they discover that this enables them to take vacations without being tethered to a work device, they will thank you.</li>
<li>Change Management - Do an appropriate level of planning and documentation of changes, and incorporate this into your processes to support audit requirements and aid in identification of causal effects. Manage change so that risk is minimized, and recovery from change can be reverted without a significant amount of effort.</li>
<li>Incident Reports - these are extremely helpful in developing an understanding of impact, and causal effects when something significant goes awry. Reflection and openness are necessary to change processes and mitigate future risk. Again, do not spend five days documenting an incident that was minor - and that only merits minimal documentation of the issue, impacts, and lessons learned to help reduce future risk and improve recovery. There are times when risks must be accepted, and that's okay as long as the risk and potential impact has been mitigated to an acceptable level. Our greatest failures can provide the best learning opportunities.</li>
<li>Meetings - maximize efficiency by preparing for the meeting, and having a clear agenda. Document follow-up items, delivery dates, and ownership. Not preparing leads to wasted time. Having nine people wait for ten minutes for the tenth person wastes 90 minute of productivity that cannot be recovered. Preparation should be appropriate for the topic and audience.</li>
<li>Communications - Appropriate levels of communications are critical. Too little communication, and your stakeholders are uninformed and can become unpleasantly surprised. Too much communication and your messages are ignored. Work with your stakeholders and staff to establish a level of communications that is appropriate.</li>
</ol>
<div>
The most important part of this is collaborate with your team and stakeholders to define a level of process that is consistent and appropriate. Be inclusive and transparent in the discussion, accepting and acknowledging feedback to develop processes that improve overall efficiency. Most importantly, evolve your processes to continually become more efficient. Perfection is often something we cannot afford in our lives. The sooner we acknowledge this, the more efficient and effective we become. Be a good steward of your resources, and strive for customer satisfaction and good stewardship. If your services are not affordable, you will not be in business or servicing your customers for any length of time.</div>
<div>
<br /></div>
<div>
That's it for this post... until next time... lead and manage for success!</div>
<div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<br /></div>
Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5266891484441380662.post-37217561755651851272015-02-01T23:28:00.000-05:002018-09-09T22:13:02.567-04:00Designing a Requests For Proposal<div class="separator" style="clear: both; text-align: center;">
<a href="http://2.bp.blogspot.com/-IoN0yQaUP5E/VM75MvwzvuI/AAAAAAAAAFM/O42miKUhfHc/s1600/RFPImage.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="182" src="https://2.bp.blogspot.com/-IoN0yQaUP5E/VM75MvwzvuI/AAAAAAAAAFM/O42miKUhfHc/s1600/RFPImage.png" width="320" /></a></div>
I like to investigate and understand business requirements, that's one of the reasons I have enjoyed participating in the design of RFPs, as well as why I like developing solutions and services. Both provide an opportunity to understand business processes from end-to-end, and to look for ways to optimize and improve them as part of any new technology undertaking.<br />
<br />
Well, it's been a couple of years since I started this post, and I said I'd add more details when I originally penned this article. I'm back at it... so I'm revising this post from 2013.<br />
<br />
So, you're part of a team that's been tasked to find the best technology solution for a problem, and you're not sure where to start. How do you know that you've found the best option for your organization? In this post, I'll start the walk-through process for designing a successful RFP. You may have to read this a few times to understand it. If I get chance, I'll post an example with vendor identifiable data redacted, as well the final scores. (update - I've added more details, I still owe the redacted examples...)<br />
<br />
Although I've put together several large RFP's over the past twenty five years, there's always more to learn. I've been involved in two types of proposals... one method uses a minimalist approach (just the drop dead functionality), and at the other side of the spectrum casts a wide net of requirements to find the optimal solution.<br />
<br />
The largest effort I've led spanned multiple companies in North America, and was the most complex of my endeavors because it crossed country borders. Topics such as regional taxation, language translation, local vendor support, country specific requirements, legal, and reporting requirements increase complexity. In these cases, you need an active RFP working group to assist with project that is knowledgeable and can coordinate capturing the requirements. You also need to identify qualified vendors to participate. In our case, this included SAP, Oracle, JD Edwards, and others that had deep functionality, and could provide support in multiple languages, and cover the country requirements.<br />
<br />
I've been involved several in other efforts, which were for mid-size manufacturers -- and have covered differing manufacturing disciplines from discrete, to process, to mixed-mode and engineer-to-order . Of course most of these included the full suite of financials, so it's important to include someone who understands the financial transaction flow processes, and how integrated software functions, including accruals between modules.<br />
<br />
To round out my RFP experience, I've also helped assemble an RFP for a Learning Management System replacement in Higher Education. Here's it's not about optimizing manufacturing efficiency, its more about having the tools available to offer a rich interactive experience for students and faculty that can help facilitate the learning process. Instead of a general ledger, there's a gradebook. There's a slightly different take on quality control, which includes using student metrics to enhance learning, maintain engagement, and improve retention. There are the normal interactive tools that empower the learning experience, discussion forums, activity tracking, calendars, assignment uploads, assessments, and many others that must be compared across solutions. The vendors in this market are quite different from manufacturing - and includes companies such as Blackboard Learn, Instructure, Moodle, and Desire2Learn, in no specific order.<br />
<br />
<h1>
Developing an RFP involves a number of steps.</h1>
<ol>
<li>Develop a timeline and milestones for your RFP, such as when the RFP will be released, what the vendor question period will be, when vendor responses are due, time for vendor demonstrations, evaluation complete date, when finalists will be identified, dates for the conference room pilot, negotiations period, and final contract award.</li>
<li>Make sure that you layout the timeline and requirements clearly both internally and externally. </li>
<li>To avoid confusion, and potential collusion, channel all communications during the RFP process through a central common resource that collects questions, and distributes each question and response at the same time to all participants.</li>
<li>Require the inclusion of the RFP as part of the final contract.</li>
<li>Provide some background on your business and project, including your timeline in an introductory section.</li>
<li>Identify and research some of you potential vendors and solutions, so you're more acquainted with industry and vendor terminology. </li>
<li>Identify your categories for the RFP. These could be functional areas (Marketing, Sales, Finance, etc.), technical areas (Networking, Storage, Scalability, etc.), Disaster Recovery & Business Continuity,, Student Engagement, or any of a host of topic specific areas.</li>
<li>Expand on your categories. Brainstorm... if there's a valid reason to ask for something, then include it. Don't add fluff. However, be thorough and do not stifle others ideas or requests.</li>
<li>Scale each of your questions based on how important they are... and be consistent. For example, you may want to weight quest that's extremely critical with 10 points, and one that's important with 5 points, and nice to have with 1 point. If there are "deal breakers".. those where you'd walk away from the project if it didn't have that functionality as either an extremely high score (500 points), or just discard vendors who can't achieve that functionality.</li>
<li>Don't forget to include any relevant information such as volume of documents produced over a year, users, number of miles driven, or whatever is relevant for the proposal requested. </li>
<li>If you know someone that's strong with Excel, you can create a spreadsheet to send out for the vendors to answer, then import this back to a master scoring sheet that contains all of the related weights.</li>
<li>Determine how... and if you're going to weight potential changes the vendor would make... and score those as well. Be careful in this area, especially with software... you need to ensure that each vendor understands the scope and requirements.</li>
<li>Decide how you're going to weight each category. What's more important to you? For example, if you're evaluating software, is it the Production Scheduling, or Invoicing modules?</li>
<li>Don't forget the intrinsic factors... add categories for customer references and weight them appropriately... check the Dunn & Bradstreet listings for relative business strength, including the Paydex ratings (payment history).</li>
<li>Once you're comfortable with your weightings and your team agrees, then it's time to review and score the vendors.</li>
<li>Pick a few top vendors, and send them "test scenarios" with your data, and have them demonstrate how their solution handles these. For example, if you require a custom order configuration engine with options that generates a dynamic bill of materials, then have them demonstrate that functionality as part of the review process.</li>
<li>Visit customers, and see how happy they are, and watch for non-verbals to see if they are really happy. Ask some questions, and don't be afraid to probe for potential strengths and weaknesses.</li>
<li>Make sure you work with the vendor, and know that they understand your requirements for important questions. If there's a disconnect, there could be some issues if you cannot get confirmation that you've both got the same understanding of expectations.</li>
<li>Negotiate life-cycle costs. These costs include things like maintenance, annual increases, billable rates, travel and expense reimbursement rates, implementation fees, etc.</li>
<li>Don't pick the cheapest, or most expensive solution. Pick the most cost effective solution that meets your requirements, and that you can afford.</li>
</ol>
<br />
Make sure your requirements are concise.... don't let things up for interpretation. For example -<br />
<br />
Supports payroll interfaces - <i><b>a very poorly question open to interpretation</b></i>... what type of interfaces? General ledger, payroll, taxes, electronic reporting, direct deposit, timecard, what? If I'm a vendor, and I support any interface, or remotely create an interface - Yes, it's a resounding YES, I have this!<br />
<br />
Be clear!<br />
<ul>
<li>Supports real-time payroll interface to general ledger for all associated module entries, distributed by department.</li>
<li>Supports real-time payroll interface to Kronos time-card system for weekly, bi-weekly, and monthly payroll periods. </li>
</ul>
I'll try to post some examples of solid RFP questions and evaluations in a future iteration. Where possible, do this electronically to make it easier on your vendor, and your review team.<br />
<br />
Here's the index from the most North American RFP I led... with some generalizations...<br />
<ul>
<li>Instructions - for completing and submitting the proposal, or escalations\ questions.</li>
<li>Quotation - defines how you want this proposal quoted, options, terms, etc.</li>
<li>Company Introduction - provides an overview of the company, locations, size, etc.</li>
<li>Subject Matter / Modules:</li>
<ul>
<li>Purchasing Section</li>
<li>Accounts Payable Section</li>
<li>General Ledger Section</li>
<li>Accounts Receivable and Credit Management Section</li>
<li>Invoicing Section</li>
<li>Distribution & Warehousing Section</li>
<li>Quality Control Section</li>
<li>Process Manufacturing Section</li>
<li>Inventory Control Section</li>
<li>Cost Accounting Section</li>
<li>Marketing Section</li>
<li>Sales Order Entry Section</li>
<li>Shipping Section</li>
<li>Environmental Section</li>
<li>General Section</li>
</ul>
<li>External Interfaces - do you have other systems to interface, or specifications you need tools providers to follow for industry standard interfaces?</li>
<li>Vendor Background - support hours, languages, response times, etc.</li>
<li>Document Volumes - scale, availability requirements so the system can be properly sized.</li>
<li>Vendor Comments - an area for a vendor to highlight specific strengths that set them apart.</li>
</ul>
<div>
<br /></div>
<div>
No vendor can do everything, I'd suggest following some process like below... and have them select from one of the following for each item, with appropriate costs or caveats. (Remember, your questions are CLEAR, so caveats are probably a partial meets.)</div>
<div>
<div>
<ul>
<li>X - Existing functionality - as stated in the question.</li>
<li>R - Available using an end-user report writer requiring no programming.</li>
<li>C - Customization available through programming (cost estimate should be included).</li>
<li>U - Unavailable functionality.</li>
<li>F - Pending Future release, due within 12 months, with estimated release date.</li>
</ul>
</div>
</div>
<div>
<br /></div>
<div>
So you get your RFP's back... what do you do?</div>
<div>
<br /></div>
<div>
If you've worked ahead, either while you were assembling the RFP, or while you're waiting for Vendor Responses, you you've had time to weight each of the questions by importance, as well as created weights for the sections, including proposal total and life-cycle cost, and intrinsic attributes of the vendor.</div>
<div>
<br /></div>
<div>
For the most part, it's now simple algebra... you take the question weight * the points for the vendor response (below) to develop a mathematical model of how well each solution fits your business. You do the same with each section to equalize this so sections are rated on importance to the project, not the number of questions in the section.</div>
<div>
<br /></div>
<div>
For example, you may want to give the vendors the following points based on their responses...</div>
<div>
<ul>
<li>(10) - Existing</li>
<li>( 5) - Reporting</li>
<li>( 2) - Future</li>
<li>( 1) - Custom</li>
<li>( 0) - Unavailable</li>
</ul>
</div>
<div>
Someone with strong Excel skills can do develop the models and formulas, then just cut and paste the vendor responses to automatically score them and quickly adjust category weights. That's the process I've taken historically. To avoid bias, or any impression of impropriety, it's critical to have your question and category weights finalized before you start to evaluate the responses. Make sure that you read the RFP responses thoroughly, and get clarifications on questions that were answered ambiguously.</div>
<div>
<br /></div>
<div>
Make sure you do proof of concepts for your critical functions as part of the review process, and plan to implement and evaluate a pilot process (if applicable) as a contingency to the contract. Don't be afraid to include the RFP or key sections in the final contract. Finally, get everything clarified and in writing - it'll lead to a more successful implementation and a a better long-term partnership.<br />
<br />
Good Luck! Used correctly, the RFP is a great tool to ensure that you're getting the best value.<br />
<br />
Reposted from Aug 24, 2013 blog entry.</div>
<ol>
</ol>
Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5266891484441380662.post-53781589252990289232014-09-13T14:29:00.002-04:002018-01-20T11:00:56.764-05:00The I in Team (Te-I-AM?)<div class="separator" style="clear: both; text-align: left;">
<a href="http://4.bp.blogspot.com/-ANTvK73Rwcc/VBSLPBl1aGI/AAAAAAAAAE4/LCO9bRASH_0/s1600/teIam.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="256" src="https://4.bp.blogspot.com/-ANTvK73Rwcc/VBSLPBl1aGI/AAAAAAAAAE4/LCO9bRASH_0/s1600/teIam.png" width="320" /></a>OK, so we've all heard it... there's no "I" in team. However, if you squint just right, and tilt your head a little to the left... you can see there is a "ME"... which doesn't leave any room for giving credit to you. Shuffling the letters a bit, you can get tea, meat, at, ma, am, mat, mate, tame, item, and so on... however, you're just shuffling the letters, and not adding value. Do you shuffle letters and take credit, or do you really add value?</div>
<div>
<br /></div>
<div>
So, in this brief thought piece, please take some time and ask yourself one simple questions? Are you a team player, or do you shuffle letters that don't add value and then take the credit? I believe humility is one thing that's very undervalued and often overlooked in our society. Leaders lead, they don't focus on constant jockeying to make themselves look better for their next opportunity. That's self promotion and salesmanship, and it often can come at the expense of their team.</div>
<div>
<br /></div>
<div>
Yes, I hear the chuckles... if you don't promote yourself, then who will promote you? My attitude has always been, if your team's doing a great job... then the entire team should get recognized for their contributions. You'll be recognized for your contributions, if your contributions really add value. That recognition may come from above, below, or from a combination of areas. Success stands out from the crowd, or at least it should.</div>
<div>
<br /></div>
<div>
We become stronger leaders by promoting the "true" success of our teams, the "business value" that they add to your organization, and giving credit where it is due. When we lead by example, they we encourage our team to reflect our attitude, ethics, sense of shared responsibility, ownership, and collaboration across the enterprise. Encourage your team to work smarter, not harder... take measured risks, and publicly give the team the credit they deserve. Add value by removing obstacles, coordinating across the enterprise, keeping a pulse on your projects,... roll up your sleeves, and really add value.</div>
<div>
<br /></div>
<div>
<h1>
You succeed and fail as a team.</h1>
As a leader, sometimes we need to take responsibility for a failure to lead. That doesn't mean protecting incompetence, that's a different subject, and outside of the scope of this brief piece. Taking responsibility means that you're willing to take measured risks as part of a continuous improvement process. Your staff should be confident that you support them. If they follow best practices, yet misjudge mitigation of a risk from the introduction of changes in your product or processes, they should be confident that they aren't going to become a sacrificial lamb. Risk should be managed and mitigated, not completely avoided. You should publicly acknowledge any incident; explain clearly what happened, and how you plan to mitigate this risk to prevent a recurrence of a similar event in the future.</div>
<div>
<br /></div>
<div>
Let's go back to business value. I like to use the perspective, as draconian as it sounds, if I owned the company, would I be willing to pay another staffer out of my own pocket for doing EVERYTHING that I'm doing? What does the company get back? If I wouldn't pay me, then why am I doing it? (And if you're honest, you already know you have some of these activities, we all have them.) You wouldn't pay a lawn-care company a million dollars to mow your one acre lawn, no matter how good it looks. You'd pay the market rate, and expect a well manicured lawn. You wouldn't want the workers swimming in your pool while they are on the clock, surfing on your computer, or any other of other things that don't improve the looks of your lawn.</div>
<div>
<br /></div>
<div>
There are activities that add value such as team building, because they teach staff to be more productive as a group than they could be as individual workers. I'm definitely not being critical of these type of activities. I'm also not talking about professional development, research, and networking. These are all highly valuable activities that lead to improved skills, processes, methods, and communications. I'm talking about activities that really add no value.</div>
<div>
<br /></div>
<div>
Finally, leaders try to hire people who are the most qualified for their open positions, are capable, share their approach to team work, have the same level of commitment, and take pride in their contributions. Leaders focus on ways to provide stretch opportunities, give frequent constructive feedback on opportunities for improvement, and provide examples where staff are leveraging their strengths. Leaders challenge their team to excel.</div>
<div>
<br /></div>
<div>
So in summary, here's a few thoughts.</div>
<div>
<ol>
<li>Lead by example, not by words.</li>
<li>Promote the accomplishments of your team</li>
<li>Look for continuous improvement and innovate, while mitigating risks. When you fail to mitigate properly, accept responsibility, and use it as a learning opportunity.</li>
<li>Recruit, hire, develop, and retain the best staff.</li>
<li>Focus on continuous process improvement and employee development.</li>
</ol>
</div>
<div>
That's it for this brief piece. Hopefully it causes you to think critically in one of the areas I've covered. Ask yourself, are you adding value in all that you do for your team? No squinting is required - approach this with your eyes wide open... be critical... and reflective. Do you see an I, me, or a team?</div>
Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5266891484441380662.post-27777770285036506382014-07-10T00:49:00.002-04:002018-01-20T11:02:26.061-05:00Think Strategic and Act Tactical!Being strategic with technology means treating your IT plans as a living and breathing organism that needs fed and nurtured. There is no auto-pilot, or silver bullet. Technology needs to align with business strategies to achieve optimal results. When the technology strategy supports business goals, the business can be agile, execute its strategies, and seize new opportunities.<br />
<br />
From an information technology perspective, small organizations tend to be more streamlined and agile than their larger counterparts. In my experience, part of this reason is because they don't have the complex requirements of larger organizations. They can be more efficient by focusing resources on visible projects that directly add business value. They don't have the underlying scale and bandwidth issues that convergence creates, nor the complexity of a large scale distributed security model. I do think we also need to differentiate between those activities that are necessary, and those that do not add value when compared with the true cost of their delivery. I'm a big fan of keeping it simple, except when the added complexity better prepares you to respond to future opportunities.<br />
<br />
In large organizations, technology is like an iceberg. The part that everyone sees and evaluates is the ten to twenty percent above the water. The eighty or ninety percent of the iceberg under the water is necessary to support the technology strategy in a complex, diverse environment. Your actual percentages aren't as important as the analogy. Above the water, we have the user facing outputs. These include outputs that enable the business to deliver its products, and data that supports sound decision making. Your business produces a product or service that adds value, such as knowledge gained through <u>online learning</u>, a cheerful living space supported by large <u>architectural windows</u>, or confidence while working in an underground mine that's protected by a trusted <u>roof support system</u>. What is your contribution to the business?<br />
<br />
<a href="http://4.bp.blogspot.com/-ToDaH0Z7yAI/U85s-g_YM3I/AAAAAAAAAEc/ukVFjoyJRnY/s1600/IceBerg.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="280" src="https://4.bp.blogspot.com/-ToDaH0Z7yAI/U85s-g_YM3I/AAAAAAAAAEc/ukVFjoyJRnY/s1600/IceBerg.png" width="320" /></a>What is the part of the iceberg that's below the water? Well, that's all of the things we do every day to get to the point where we have a strong foundation of technology that permits agility and responsiveness to business <br />
opportunities. The eighty to ninety percent? These are the things that business executives take for granted, or don't know that are needed to support visible services. They want an integrated communications system, and don't need to know that its supported by an SMTP, POP3, or IMAP server. They want secure access to information on the web, without knowing about firewalls, proxies, and virus protection. They want to know how many widgets they sold, and don't care about the database, operating system, network, switches, VLANs, or programming language necessary to deliver actionable information. They want an end product. It's our responsibility to plan for the 80-90% below the surface. We need to act as if we are selling a solution that adds value to our organizations. As experts, we should act like an auto service center, and not like an auto parts store.<br />
<br />
Companies with a vision know where they want to be in five years, and they are executing steps in a business strategy to prepare them for success. As technology professionals, we need to know that destination and milestones along the way, so we can be prepared to support opportunities as they arise. Businesses cannot wait for us to build the 80-90% below the surface, they can barely wait for the 10-20% above the water. That's where we need to be strategic. Oh, and the difficult part... is convincing businesses that they need to invest in the 80-90% so that we can be agile in delivering the 10-20%. It's like building a house. You may be ready to sleep in your new bed at your soon-to-be-built home. However there is a lot of preparation, planning, and construction necessary to build the foundation, walls, roof, and the rest of the house. All of this needs to be completed before you have a place to put your bed, and get a good night's sleep.<br />
<br />
I've had many conversations with business executives and leaders over the years, and there's one question I've asked that has solicited many different responses... "Where do you see this company in five years?" Organizations with a well thought strategic plan often asked follow-up questions... such as... are you talking markets, products, or growth? Companies that lack vision often struggled to form a response beyond they want to survive, or want to grow, yet lack any cohesive planning to support their goals. Follow up questions on how IT can support that strategy are often met by vague answers... and questions of why it's important for IT. There is a perception that IT is only the 10-20%, and "can't they just let us know when they need the service?" However, it takes careful planning and execution to build solutions to enable success.<br />
<br />
I've learned over my career that as leaders, we need to maintain targets to focus and challenge our teams. This is our strategic direction, it's where we believe we need to be at different milestones over five years to support realization of the business plan, with some type of agility. It's much easier to get a good night sleep if I have a place to put the bed, and don't need to wait for someone to dig the foundation. We should be judged on the quality of services we provide, not on heroic efforts that mask a lack of vision and strategic planning. We cannot provide reactionary excuses for why we can't deliver results by tossing grenades over the wall and blaming others. It's our responsibility to ensure that we can support our customers.<br />
<br />
Milestones form the tactical piece. It's important to provide deliverables, and to keep a pulse on changes that may affect the overall strategy, or business landscape. By acting tactically, and thinking strategically, we can develop digestible projects and milestones that form steps in getting to our final destination. We should get feedback from the business as we deliver interim "services", so we can adjust the strategy to support changes, and adjust our trajectory as appropriate.<br />
<br />
I do believe in developing multi-phased long-term projects, with periodic planned releases and milestones. Based on the project, we normally establish bi-weekly or monthly working group meetings. I've found if you want to deliver projects that meet the customers' requirements, have your technical team provide frequent updates and get feedback. You'll often discover requirements that may not have been communicated, or interpreted correctly... and can be adjusted before they have any significant impact on your project.<br />
<br />
In summary, thinking strategically is equivalent to knowing that you need a place to live, and planning each phase of construction. Acting tactically is the business of construction. It's delivering milestones like excavation, masonry, framing, plumbing, electrical, roofing, and finishing work. If you find that you're building on a slate outcropping, you can adjust. If the weather delays framing, there is also an opportunity to revise your plan. You can add resources, sub-contract, outsource, or decide that the delay is acceptable. It's all about understanding that plans should be living organisms that evolve with business requirements. There isn't a one-size fits all solution, and different organizations have different requirements based on size, geography, organization culture, economics, market, product, and other factors. Plans shouldn't be put in a drawer and revisited once a year.<br />
<br />
That's it for this post. <br />
<h1>
Remember, think strategically... and act tactically!</h1>
<br />
<div>
<br /></div>
Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5266891484441380662.post-91623293110768124902014-06-11T23:27:00.001-04:002014-07-08T22:05:50.436-04:00Technology as an enabler!I've had several conversations with my staff recently. These conversations were about technology. I find that often people get caught up in the business of technology vs. the technology of the business. The difference is subtle, yet important.<br />
<br />
I had an opportunity to have a recent conversation with my son, a Penn State student who was reviewing for an upcoming exam covering technology. It was a little technical, from my opinion, for a Hotel Restaurant Institution Management (HRIM) Major. He asked me the difference between a CTO (Chief Technology Officer) and a CIO (Chief Information Officer). My prospective has always been that the CIO straddles both disciplines... the CTO, however, is more firmly situated on the technical side of the house.<br />
<br />
CIOs are people with one foot in the business, and another in technology. They focus on ensuring that technology projects are properly staffed and funded, and align with the requirements of the business. They are not fully a business executive, nor a technology executive. They can provide technology leadership and bridge communications obstacles between technical and business leaders. This may include requirements for improving inventory turns, integrating new acquisitions, or speeding receivable collections. They are savvy in justifying the need to invest in technology in a way that's easy to understand for business executives. They are "bilingual", and can communicate with both technical and business leaders on their levels.<br />
<br />
<div>
I'm in an ITS Collaborative group. We've recently been discussing the differences between roles. I - information role, with a business focus... IT - one foot in each discipline, and T - with a fully technical focus. Depending on your customers, there is a requirement to meet them on their terms, and discuss their needs using terms familiar to their discipline. Where are you? Are you an I, IT, or T? Or, does it depend which project you're undertaking, and which customer you are engaging.</div>
<div>
<br />
The bottom line is simple, in IT we must provide a service and add value. If we cannot communicate with our customers, then we will be unable to meet their requirements. We should be trained on optimizing business process by reviewing them with an fresh, independent perspective. Technology should enhance an add value to a business by streamlining processes, improving access to data, and empowering continued growth for a business. We need to be able to identify the value we add, and communicate payback on technology investments using terms common to the disciplines we serve.</div>
Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5266891484441380662.post-83589716890880282492014-06-11T23:03:00.000-04:002014-06-11T23:28:17.524-04:00Let's talk performance...Ok. I admit it. No matter how much I try to position myself as a pure business executive, I sometimes have a tendency to revert to my inner geek. You know, it's that conversation that switches to performance, and all of the sudden, you remember everything you've learned about performance.<br />
<br />
So, I thought I'd make a few general observations. I was reading an article on Linked-In today, about how some people make assumptions that everyone else knows what they know... or that some of this stuff is just common sense. I think sometimes I fall in that group. So hear goes....<br />
<br />
<br />
<ol>
<li>The more you expect from a system, the more effort you need to put into tuning it properly. E.g. it's easy to run Microsoft's SQL Server. It's much more difficult to do this at a very large scale.</li>
<li>Just because a system can auto-tune itself, it doesn't mean that it's can be much better with a great performance tuning expert.</li>
<li>It's really easy to make good software suffer from a performance perspective, and then blame the software.</li>
<li>There are MANY people in this world that claim to be expert. They are so overly confident that they have convinced themselves that they are the ONLY competent people. There's always someone smarter, better, and probably with better people skills.</li>
<li>Databases like lots of dedicated memory. If you have it, make sure it's preallocated and tuned properly.</li>
<li>Databases like lots of IOPS.</li>
<li>Faster spinning disks get more IOPS.</li>
<li>More spindles /disks gets more IOPS.</li>
<li>Proper raid level planning is critical for performance.</li>
<li>Selecting the correct raid level has a significant impact on performance, and needs to be aligned to the purpose required.</li>
<li>More cache is a good thing.</li>
<li>SSD helps performance when properly configured to remove bottlenecks.</li>
<li>SSD normally goes through a controller, PCI Solid State drives are on the bus, and have an opportunity to run much faster.</li>
<li>PCI SSD, properly planned, and with a recovery strategy can reduce the need for lots of spinning disks. They do need to be part of the recovery strategy, should your PCI SSD fail.</li>
<li>There is a tradeoff between faster processors, more cache, and more cores. Evaluate this and make the best choice for the load profile.</li>
<li>Database planning is important.</li>
<li>Database tuning is required.</li>
<li>Database recovery requires log files. You can't roll forward if you don't have a full backup with all of the incremental log files.</li>
<li>Database backup strategies can include cold backups, or a combination of logs and exports, and varies depending on uptime, and acceptable downtime and data loss.</li>
<li>Networks must be properly planned in order to be both secure, and to scale properly.</li>
<li>Firewalls are critical to securing a network.</li>
<li>Performance testing much be consistent, and repeatable.</li>
<li>Production environments must be monitored and tuned.</li>
<li>Systems must evolve, users aren't static, and neither should be our systems.</li>
</ol>
<div>
<br /></div>
<div>
I could go on... It's been a while since I posted, so I thought I'd do a quick performance memory dump tonight. Thanks to this, I can now switch back to focusing what's important to the business, and being more leaderly.</div>
<div>
<br /></div>
Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5266891484441380662.post-28700201737349917632014-02-12T12:46:00.000-05:002014-02-18T23:52:40.873-05:00What does it take to succeed?<div class="MsoNormal" style="margin-left: 0.25in;">
Team skills and culture play a
critical role in the success of projects. I have a group of dedicated
developers that leave their egos at the door, and work together as a cohesive
unit. We are looking for ways to continually improve our overall skills and
improve our processes so we can be more effective in managing our projects. We
ask for continuous feedback from our customers and adjust our project
trajectory as appropriate. We focus on the little things, and try to monitor
the pulse on our project to expose potential surprises early, so we can work
with our customers to compensate for these changes. Project success is about focusing
on how we add value to our customers, and trying to improve this every day, through
an iterative approach. <o:p></o:p></div>
<div class="MsoNormal" style="margin-left: 0.25in;">
<br /></div>
<div class="MsoNormal" style="margin-left: 0.25in;">
Regardless of the development
technique to which we subscribe, if we don't add value and serve our customers,
our techniques, and results, are basically irrelevant. We need sufficient
process to predict project outcomes, without constraining our potential for
success. We need to use common sense and moderation to identify the correct
balance for our individual teams.<o:p></o:p></div>
<div class="MsoNormal" style="margin-left: 0.25in;">
<br /></div>
<div class="MsoNormal" style="margin-left: 0.25in;">
Here’s some of my basic
observations on what it takes to succeed…<o:p></o:p></div>
<div class="MsoNormal" style="margin-left: 0.25in;">
</div>
<ol>
<li>A dedicated team, and an honest
feedback loop – the team is organic, and should feel safe to provide feedback
on shortcomings, potential for improvement, potential new techniques, and strengths
that can be leveraged.</li>
<li>An ego-less culture – staff must
be comfortable to brainstorm and provide feedback, regardless of level. They truly value each other’s opinion, and
look for ways to continuously improve processes.</li>
<li>A focus on quality, openness, and
customer service. It means sometimes
accepting responsibility, even when you may not agree that you are at fault… as
a way to move forward.</li>
<li>Focusing on the customers’
project, and talking on their terms… in their language. They need a solution which they can embrace and understand, and not a bunch of technical details which are important to deliver the solution... yet are NOT the solution.</li>
<li>Really understanding what the
customers’ needs, and asking probing questions to help define and agree up
front to the project scope and document the assumptions / specifications so
scope creep can be identified.</li>
<li>Prototype to get buy-in from the
customers… and work with them to adjust the deliverables, resources, or timeline
as appropriate. If the scope changes,
negotiate one of the above variables to keep the project on schedule… and provide immediate
feedback on impact to your customer.</li>
<li>Put together a detailed project
plan… with a clear critical path… e.g. 1000 hours out of a budget of 2000 may
be 10% complete or 50%... if you can’t tell, then break the project plan down
further… and also rely on feedback for % effort complete, don’t go by hours
alone.</li>
<li>Frequent meetings with your
customers to show current progress and get feedback. You’ll find that they often missed important
details as you demo project progress at weekly, biweekly, or monthly meetings.</li>
<li>At every meeting, update your
timeline… if there are risks, identify them early, and discuss them with your
customer. I would want to know early if
my house won’t be finished for a few more weeks… not after I have the moving
van packed and I’m on my way across the state.
Give your customers the same courtesy.</li>
<li>Evaluate new tools and
techniques. Pick some unobtrusive way to
test these, and adopt new processes and techniques after you've proved their value.</li>
<li>Find ways to innovate
transparently. One of the recent things
we've done is to deploy code without an interface, and off… so we can evaluate
performance with the function enabled, and not visible. It's easier to remove this via a setting, and
the customer isn't disappointed because a feature needs refactored to perform
at scale.</li>
<li>Recruit and develop your staff for
success. Get staff that share the same
dedication to customer service, and make them comfortable in your
environment. Look for team players, and
provide them continuous feedback.
Reviews should be a reinforcement of feedback you provide on a daily or
weekly basis… and nobody should be surprised… or there is a management failure.</li>
<li>Quality should be part of the
process, as should involving customers in the testing and acceptance
lifecycle. It shouldn't be an afterthought. If we consistently require heroic efforts,
then we need to review to see where we have failed in the planning and
communications process.</li>
<li>Ownership doesn't end when code is
submitted, it’s a lifecycle approach, and shared across the team. It’s part of that continuous feedback loop.</li>
<li>Recognize your team for their results, and make sure they get the credit that they deserve.</li>
</ol>
<div class="MsoNormal">
In the end, it’s all about finding the right balance of
tools, processes, and techniques to improve the services you provide your
customers. Ask, and get feedback... and be sure that you are capable of humility and openly accepting all comments.... even those for which you may passionately disagree. Perspective and lens are individual, accountability and goals are not... so keep your eye on the prize and evaluate against measurable results, not effort.</div>
Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5266891484441380662.post-42370515022703783862014-02-11T12:24:00.000-05:002014-02-11T21:37:15.456-05:00Research Projects vs. Continuous Improvement for Production ServicesThere should be a clear distinction between a research project and a production service. I’d like to do a brief contrast and comparison of where these overlap, and where the concepts diverge. Let’s say a developer want’s to introduce a new process change into the development life cycle, or into the hosting life cycle. How do you define if what’s being change is part of continuous improvement, or is a research project? There are several litmus tests…<br />
<ol>
<li>Has the technology been proven in a pilot process, and is there a direct proven benefit to product quality, stability, and customer service?</li>
<li>Is the outcome learning or proving the value of a technology?</li>
<li>Has the technology been proven, and is the application of the process or technology easily repeatable for other applications?</li>
<li>Is there a measurable benefit, and is the risk from the change mitigated with an expected benefit?</li>
</ol>
To contrast and compare…<br />
<br />
<table border="1">
<tbody>
<tr>
<td>Attribute</td><td>Research Projects</td><td>Continuous Improvement Project</td>
</tr>
<tr>
<td>Expected Value</td><td>Knowledge, any other value is a bonus</td><td>Either explicit, or intrinsic improvement</td>
</tr>
<tr>
<td>Cost Recovery Model</td><td>Sunk / No Option for Recovery</td><td>There is a payback or cost recovery period</td>
</tr>
<tr>
<td>Proven Technology</td><td>Proves Hypothesis</td><td>Yes, this is either an application of a technique to a new system, or an evolution of an existing process.</td>
</tr>
<tr>
<td>Known Outcome</td><td>No, the potential for improvement may be radical, however the risk is unknown.</td><td>Yes, with a very high likelihood of success</td>
</tr>
<tr>
<td>Level of Risk</td><td>High, first tested on low impact situations</td><td>Low, the technology has been proven.</td>
</tr>
<tr>
<td>Production Ready</td><td>No</td><td>Yes</td>
</tr>
</tbody></table>
<br />
A continuous improvement project is one that improves on existing processes in a risk-mitigated fashion. It is evolutionary in nature. Research projects are attempts at revolutionary changes to processes, and are equivalent to a larger scale lab project to learn more about a process, and to evaluate the potential for improvement. Once research projects have been proven, then the new process is mapped to existing processes, and a gap analysis is completed. As part of the gap analysis, production processes are compared as evolution using moderate steps through continuous improvements to reduce risk. Research projects are similar to a petri dish experiment… and can be anything from a proof of concept, to a radical change in processes or technology.<br />
<br />
Because production services are expected to be stable, changes are introduced using a method that reduces risk. The change is normally evolutionary, with prior proven steps, and a proven change management process. Once the research project has proven successful, then it needs to be mapped, and evaluated based on its potential as a production service. This means looking through the lenses of stability, customer service, process improvement, efficiency, and value.<br />
<br />
I’m not adverse to radical changes. However these should be first proven on services which have a higher tolerance to disruption, and then migrated up the service chain. The exception of course, is when you are not meeting service commitments for a critical service, and can take a measured risk that the radical change will improve the service. Unstable systems have a different criteria for change than proven stable systems. There are a number of reasons why a system can quickly become unstable, including changes in infrastructure, rapid adoption, and inadequate sizing – all of which should be mitigated, where possible, with adequate testing. Like the commercial from a few years back… if you click the go-live button, and you are an overwhelming success beyond your wildest dreams, you could have a scalability and stability issue you need to address with radical changes.<br />
<br />
That’s it for now… Happy Computing!<br />
<div>
<br /></div>
Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5266891484441380662.post-86899499578540234882014-02-09T02:04:00.002-05:002014-02-09T02:04:56.907-05:00Ethics in BusinessAnyone who has followed my blog understands a few basic premises that I feel very passionate about as important character traits. These include:<br /><ul>
<li>Honesty - if I lost my wallet, could I trust you'd return it when you found it? </li>
<li>Ethics - will you do the right thing, every time,... even if nobody is looking? </li>
<li>Accountability - can you take responsibility for your actions or lack of action? </li>
<li>Stewardship - do you treat my money... like it is your money? </li>
<li>Humility - Can you work as part of a team of equals that shares in the wins, and losses? </li>
<li>Trust - If you learn something that is confidential, can you keep it in confidence? </li>
<li>Initiative - are you self motivated? </li>
<li>Teamwork - can you share your toys, and play well in a sandbox? </li>
<li>Leadership - can you take ownership for a problem, and circle the troops toward a goal? </li>
</ul>
Ethics is derived from the term ethos. Ethos is a greek word that means disposition, character, and fundamental values.<br /><br />Do you have fundamental values? So often I see people that lack in one or another fundamental value. I am as guilty as anyone if failing to meet my own expectations for a moral compass periodically. As I've mentioned in other posts, ethical behavior isn't always the path of least resistance. It may also not be they best way to earn your first million. However, it is the RIGHT THING TO DO.<div>
<br />There are times I've disappointed myself. I was getting gas a few days ago... and I saw a young lady pull up in an old beat-up car that had cardboard on the back window. She pumped $5.00 of gas for the car. At the time, I thought that she must really have it rough, to only get 1.5 gallons of gas. Best case, on that vehicle, it is probably 30 miles of travel. If I'd have done the right thing... I may have offered to help her. As most people, I thought about it... had an opportunity... however I didn't act.</div>
<div>
<br />Back to the article...Ethics is really a reflection of one's character. Do you do the right thing? I'm not talking about the "LEGAL" obligation. Legal obligations often don't reflect moral or ethical commitments, they are somewhere below that requirement. Some examples:<br /><ul>
<li>If your company CAN afford to pay a living wage, and for insurance, but chooses not to do so to keep more profits, and then directs their employees to public assistance, you're probably not being ethical. </li>
<li>If you see something happen that has a negative impact on society or an individual, and say nothing... you're probably not being ethical. </li>
<li>If you pay your employees under the table and convince them that you're saving them taxes, when in reality you're robbing them of their social security benefits, and saving yourself taxes... you got it... probably not ethical. </li>
<li>If you develop a confusing pricing scheme to permit you to get sales by confusing people of the total cost of your product... not ethical. </li>
<li>Taking credit for a staff members contributions... not ethical. Passing blame when you are partially to blame, also... not ethical. </li>
<li>Determining the level of respect to provide someone based on their title, wealth, or beauty vs. valuing them for their humanity. </li>
</ul>
</div>
<div>
Bad things happen in the dark... weather that's the dark corner of a city slum, or a dark corner of the internet. Light fights darkness. By shedding light on inequity, we have a better opportunity to resolve the inequity.</div>
Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5266891484441380662.post-43968872330857346722014-01-25T10:49:00.005-05:002014-01-25T10:49:48.018-05:00Set your own performance bar, then raise it!Each person is responsible for having the self-respect and pride in their work to set their own performance bar. I've worked in various organizations, and I often hear a number of complaints about staff not receiving direction, or being afraid to take initiative. This can be for any number of reasons, some valid, and some falsely perceived. The common mantra - that's above my paygrade... so as is the motto for <a href="http://francis.edu/" target="_blank">Saint Francis University</a> (one of my Alma Maters, the other...<a href="http://psu.edu/" target="_blank"> PSU</a>), "Reach Higher, Go Far!" Don't expect to move to a higher position if you don't step up and take ownership. If you can't make the decision, then get the facts and make a recommendation to someone who has that authority, or if you have time, volunteer to do it! I'm not suggesting that you lose your work-life balance by working ridiculous hours. I am saying you should be dedicated and focused the hours you do work!<br />
<br />
As a species, questioning everything is part of our God given makeup. We need confirmation that we're on the right path, and feedback that we are meeting expectations. People can get this in many areas... managers, peers, co-workers,etc. The only place that is constant, is looking internally through reflection and meditation. Proverbs 6:6-8 in the Living Bible says... "Take a lesson from the ants, you lazy fellow. Learn from their ways and be wise! For though they have no king to make them work, yet they labor hard all summer, gathering food for the winter." God reinforces our responsibility to be driven internally, not be lazy... to work hard... and set our own bar!<br />
<br />
For the most part, organizations tend toward chaos and selfish initiatives when there is a void of direction. This is because they haven't learned to focus on common efforts. There are many initiatives under way to such as the Zappos experiment with eliminating management. I'm not saying this won't work in the short term... I'd be more concerned about maintaining focus in the long term.<br />
<br />
My reservations with Zappos are based on my experience. One organization I'd worked for was heavily team focused. Clicks formed in the organization, and decisions were made on emotion instead of analysis. Decisions required consensus. When individuals focused on looking objectively vs. passionately, they were seen as a non-team player. Peer reviews were never overly honest or critical, because the reviewer would need feedback as well, so there was little honest feedback provided. (I actually had someone ask for input... followed by...you scratch my back... I'll scratch yours!) The organization shifted models several times. I was most disenfranchised when the leadership team decided to terminate their top salesperson because the person expected everyone around them to give their best effort. Rather than coach a solid performer on the need to improve their interpersonal skills, they lost one of their most gifted and dedicated employees.<br />
<br />
If an organization "has" a direction, and culture toward continuously improve processes, efficiency, and customer service, then I propose that the setting the bar is an evolutionary process and one that doesn't require explicit instructions. When everyone contributes, and focuses on some basic common sense goals... like continuous improvement, the organization continuously evolves. You don't need to be told to do something, you do it because it's the right thing to do!<br />
<br />
There are organizations that can go out of their way to prevent what should be focusing staff on improving by ensuring that goals are aligned with the organizations' requirements. These usually have systemic issues, such as:<br />
<ol>
<li>Focusing on metrics such as hours worked instead of output, responsiveness, quality, and customer service. "Face Time" is not a valid or desirable metric. It's much better to have efficient staff that properly plan, than reactive staff that are constantly putting out the next big fire through heroic efforts and working non-stop.</li>
<li>Awarding heroic efforts, vs. a well planned and stable environment as a result of proper planning, controls, and adjusting project trajectory vs. reacting to project changes.</li>
<li>Nepotism - awarding family with promotions that others deserve... which is ethical if you own the company. If you don't, then it's unfair to the other employees who are more deserving and qualified for the position and is generally accepted as unethical behavior.</li>
<li>Failure to respect or providing preferential treatment to individuals based on their race, religion, gender, appearance, or for other reasons not related to job performance.</li>
<li>Poor interpersonal skills.</li>
<li>Lack of respect for individuals.</li>
</ol>
There are many others... I'm sure you've experienced them. When you're in a toxic situation, you have three choices... grin and bear it, be the change agent, or change positions. I recommend the two latter, based on your tolerance to the stress that goes with being a change agent, and the organizations acceptance of change. In no case should you permit your position to have a negative impact on your quality of life for any longer than absolutely possible.<ol>
</ol>
<div>
Prepare yourself for the journey by putting yourself on the balcony... which means pull yourself from the situation and short term experience... elevate.. and gain perspective by looking at the big picture with a long term perspective. Setting goals isn't based on picking the perfect path and not looking back... it's about making the best decision with the information available... and then adjusting your trajectory along the way. It's the difference between living like a scud missile, or living like a smart bomb. The smart bomb can adjust, the scud can't... it travels through space aimlessly and can't adjust to changing winds, or other environmental factors. The smart bomb reaches it's destination regardless of distance by design... the scud will only do so if the initial decision was perfect and nothing changes, and the journey is short.</div>
<div>
<br /></div>
<div>
So, now you know... it's your responsibility to ratchet up your internal performance barometer... and let's see who follows! If you can lead from above.. then lead and they will follow. If not, then lead from where you are now, and prepare for the future!</div>
Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5266891484441380662.post-65738422772505365662014-01-18T23:20:00.003-05:002014-01-18T23:29:35.264-05:00Commit... and deliver!I was in a meeting earlier this week, and as a result, did some reflection on what it means to make a commitment, then follow through until your commitment has been fulfilled.<br />
<br />
Let me give a little personal background. I grew up in a traditional home with two parents, and two other siblings. My mother was a fabulous and nurturing stay at home mother. My father worked two jobs to put food on the table. He often used "we'll see" if he wasn't sure he could deliver on a commitment. However, when he did commit to anything, he'd move mountains to fulfill his promises. We had a few basic rules in our family, and I've tried my best to follow them.<br />
<ol>
<li>Follow the golden rule. Do unto others as you'd have them do unto you.</li>
<li>Finish you plate, there's kids starving that aren't so lucky... and no, you can't send your plate to them, so don't ask again.</li>
<li>Nothing is better than family and close friends... you can always count on them for a commitment.</li>
<li>Don't be afraid to ask for help, and prepare to help when asked.</li>
<li>Only say I love you if you really mean it... otherwise it becomes watered down.</li>
<li>Only commit to something that you can... and intend to deliver. Don't disappoint someone who asks for assistance or needs help. A commitment is a as close to a promise as you can get... so only make them when you plan to deliver results.</li>
<li>Don't expect recognition or compensation for being kind, or doing the right thing.</li>
<li>Don't be a drain on society, we have enough leaches.</li>
<li>An honest day's pay deserves an honest day's work.</li>
<li>You earn more respect for what you do with your commitments, words are cheap... it's action that delivers results.</li>
</ol>
<div>
I think it'd be a better world if everyone followed the same simple rules. I've tried to follow the same philosophy. If I say I will commit to something, I'll do my absolute best to make sure that my commitments get fulfilled. I believe in order to earn respect, it's important to follow-through on your commitments. This includes earning the respect of others, as well as gaining self-respect.</div>
<div>
<br /></div>
<div>
I believe that many projects fail because of a lack of commitment. This is in addition to a number of other reasons such as...</div>
<div>
<ol>
<li>A failure to define a clear objective.</li>
<li>A failure to define and measure realistic milestones and dates.</li>
<li>A failure to define clear roles for the team.</li>
<li>A failure to realize that time is money.</li>
<li>Assumptions that the work will always be someone else's responsibility.</li>
<li>A lack of meeting agendas, and assignment of follow-up tasks.</li>
<li>A failure to to properly scope a project.</li>
<li>A lack of funding, or realistic understanding of the budget.</li>
</ol>
First and foremost, without a commitment, everything else is irrelevant. A successful project requires a committed team. I'd much prefer for someone to tell me that they cannot commit due to other obligations, or they can only provide a few hours a week... than for them to fail to deliver on commitments. I think there is a basic premise that people need to understand for what it means to be committed. I propose the issue isn't with commitment, we have an issue with follow-through. A real commitment is as important to the project as it is to a marriage. Maybe that's why our divorce rate is so high.<br />
<br />
OK, a few words about some of the other items in my list. I'm repeatedly amazed by how many people consider wages "sunk costs" that don't require accountability. If you have 10 people in a room that average $40 per hour with benefits, and you have a four hour meeting... you're project just absorbed $1,600. If you schedule these every week for a ten week project. Your cost in meeting time is $16,000... and that's before you account for any work outside of the meetings, or other project costs. You'll see many other posts in this blog on other topics like objectives (project meandering), milestones (no measurement), scope (what are we here for?), and from a lack of knowledge of budge realities (e.g. shopping for a Rolls Royce when they have a Yaris budget).<br />
<br />
So, if you want to be successful, you have to hold others accountable... and be accountable yourself. Know what you want... measure your progress, and deliver results.</div>
Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5266891484441380662.post-80219442927133829472014-01-12T14:20:00.002-05:002014-01-12T14:20:40.742-05:00On Transparency & Openness: Buzzwords, or Reality?I've been doing some contemplation on what it means to be transparent and open. New Jersey's Governer Chris Christy, love him or hate him, is airing some dirty laundry over a bridge closing orchestrated by his staff to punish a mayor that didn't support his campaign. Will he be open?... and is he being transparent and honest?... are you with your customers? Ouch... there's that mirror for reflection and introspection again! I haven't watched the entire two hours of his recent interview... however... based on some highlights... he accepted responsibility, he was apologetic, and he was humbled, which is pretty amazing for an outspoken person. Humility, honesty, and ownership are good traits to help you succeed, and gain the respect of your peers.<br />
<br />
Dealing with customers requires the same type of communications. <br />
<br />
<ol>
<li>When planning a project, share details and be transparent. However, don't allow your project to be micromanaged by your customer (collaborate and compromise, however - recognize you are the domain expert for the technology).</li>
<li>There are times when you need to make hard decisions, and there is a customer impact. Don't make short-sighted decisions... know the difference between when you MUST impact your customer to protect them from an immediate threat or imminent failure vs. when you can work around their needs and requirements.</li>
<li>When something occurs that impacts your customers, then be transparent. It doesn't necessarily mean kicking ass and taking names... pointing fingers... or throwing the Junior Programmer under the bus for a first time mistake. It's accepting responsibility for the team, and providing detailed follow-up that includes details on the incident (a.k.a. and incident report). </li>
<li>The report should detail the basics...</li>
<ol>
<li>Who - was impacted?</li>
<li>What - was the impact to your customers?</li>
<li>When - was the impact, and the timeline for service restoration?</li>
<li>Where - which locations / populations were affected?</li>
<li>Why - did this happen?</li>
<li>How - did your recover, and how are you going to prevent this from recurring in the future?</li>
</ol>
<li>Look for opportunities to improve your processes and prevent future failures from occurring for the similar circumstances (called Lessons Learned). This can include process changes, additional testing, monitoring, or other improvements that could reduce the likelihood of happening, or improve the response time for recovery.</li>
<li>If you have internal issues to address, then address them objectively with education, employee development, policy, and process. Communicate this to your customers, remember that sometimes even measured and mitigated risk still result in a failure or process breakdown. Mitigated doesn't mean eliminated.</li>
<li>There are times when you may need to take personnel actions... and when you do... for the respect of the individual, team, and yourself... follow policy, be discreet, and where possible, look at it as a learning opportunity. If there are too many learning opportunities... maybe you've not properly mitigating risk, have policy problems, or quite possibly, you may not have hired the right person for the position.</li>
</ol>
A number of years ago, when I directed IT for JennMar Corporation, one of my developers released a bug that was pretty visible to our executives. One of the executives called me, he was looking for someone to "ream out, take names, and kick ass". My response was... go ahead... it's my department, so regardless of who made the mistake, I'd handle it internally. If they needed a name to blame, it was ultimately my name... my department... my responsibility.<br />
<br />
I handled the issue internally, it was a learning opportunity for a solid developer, and my response gained respect from the executive... since it demonstrated a sense of departmental ownership. It also gained respect from the developer, since he worked for someone that didn't take his credit and pass blame. (Yeah, I hate to see those people in any organization too!) Give credit where credit is due, take responsibility for properly mitigated risk (not the same as a blatant disregard for rules - that's a train wreck), and work to continually develop your team... and... get their feedback so you can continue to improve your skills as well.<br />
<ol>
</ol>
<br />
<br />
<br />Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5266891484441380662.post-39895406248516095422013-11-23T14:52:00.000-05:002013-11-23T14:52:00.084-05:00Technologists... keep your eye on the prize! Results!First, let me preface this post... and admit I do have my "favorite" development tools, architectures, etc.. I believe that continuous development of technology skills, programming, network, etc. are important. However, you should judge your success on the quality of products you deliver your customers, not the number of lines of code you develop. The latter are irrelevant to your customers, as is the underlying technology.<br />
<br />
Let me say that from my customers' perspective... they couldn't care if our projects are developed using Ruby on Rails, python, PHP, or ASP.NET. They want applications that serve their requirements, that are user friendly, and that can be delivered on time. Technology is about preference, and efficiency. Obviously, it's much easier to develop in some languages and tools than others... and some tools lend themselves to improved interface design.<br />
<br />
Delivering results comes down to understanding the requirements, and getting the best tool for the job, then designing to meet customer requirements, and delivering excellent customer service. My customer has no idea what's under the hood. <br />
<br />
Do you care about the material composition of the metal in your engine, or is it sufficient to know that it comes with a 100,000 mile warranty? You judge the quality of the car by how well it runs.... not the composition of the metals... or brand of computer chips that controls the engine, or offer creature comforts. It's about delivering results, on time. If you order a car, and it takes three years to receive instead of six weeks, are you satisfied? What if it was because they wanted the car to be 100% perfect, and that takes time... and your car is over-budget by five times? Or, will you settle for a few minor blemishes, and get it in budget within the time guaranteed? Oh, and how much magnesium was in the engine block? At this point, who cares?<br />
<br />
I am very interested in technology... my customers are not... they want results. They shouldn't need to know the technical details... I need to meet them on their communications level, and talk their language. When people focus on technology, they may lose site of the customer requirements and desires. If you have no customers, you have no need for technology.<br />
<br />
So, focus on what is important... results... deliver these on-time... using whatever technology you prefer... and one which is transparent to your customer. There are too many projects that fail because technologists lose site of the prize, don't let yours suffer the same fate. It's about balancing technology with customer requirements, and staying within budget.<br />
<br />
<br />
<br />
<br />Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5266891484441380662.post-27515191852851392322013-11-23T14:20:00.001-05:002013-11-23T14:20:08.319-05:00Employee DevelopmentEvery day... we learn something new. If you don't, you have a closed mind... or your dead. We learn from many avenues, such as books, TV, our children, friends, peers, managers, and others. We learn both positive and negative habits, as well as new information. Some of this educates us, others hardens us... and yet others drive us to compassion.<br />
<br />
What is your role as a manager in employee development? It's helping to continually improve your staff, and preparing them for the next challenge in their career. Like marriage... two way feedback is necessary to develop a mentoring relationship. I try to follow a simple philosophy... challenge my team to continue improving and evolving... and try to listen for feedback on ways to improve. Am I always successful, no. It's the team's engagement in their development and sense of ownership that really drives this process.<br />
<br />
One of my new members on my team was surprised by the "lack of egos". I thought about this for a while... and I must say that for the most part... he's correct. Egos and confidence are two different things. We are a very confident team, and very customer service focused. Since we focus on knowledge sharing and continuous improvement... our culture allows us to have the humility necessary to ask for feedback and assistance from other team members... regardless of their level. Everyone contributes, and you level doesn't limit your ability to contribute and make a difference. It also doesn't prevent staff in a higher grade from recognizing areas of expertise in a level-agnostic way, and asking for assistance on a regular basis.<br />
<br />
So, how should we go about employee development?<br />
<br />
<br />
<ol>
<li>Be deliberate - take time to observe, evaluate, and provide feedback often.</li>
<li>Be objective - try to approach each opportunity for feedback with an open mind. If something occurs, and you can't be objective, write down your feedback... wait a few days... and then deliver it in a statement of fact method.</li>
<li>Be timely, not reactive - If you deliver the feedback in a rash way when you're upset... or wait to long... it won't be viewed as career development... but lashing out... or bringing up the past.</li>
<li>Be reasonable - evaluate staff at their grade... any improvement above that level is being a good mentor and preparing them for either a promotion, or the next opportunity.</li>
<li>Don't surprise - if you wait until once a year to give feedback... shame on you. Annual reviews should never be a surprise... they should be a confirmation of conversations that have occurred over the year on employee development matters, and to set objectives for the future.</li>
</ol>
<div>
<br /></div>
<div>
I really like the idea of holistic continuous feedback. If your employee is a level one... and their focus is technical, then focus on their technical skills and attributes necessary to get to a level two position. Once they achieve level one... then focus on the development necessary to get to level two, and so forth.</div>
<div>
<br /></div>
<div>
Don't have tunnel vision. Focus on all attributes... if someone has expert level .NET Skills... maybe they could use some development in SQL Server... or additional testing skills... responsive design, etc. Don't forget feedback on team interaction, some people don't recognize themselves as leaders... and others don't recognize that they may be abrasive. Give feedback on improving communications, being responsive, managing projects, improving presentation skills, etc.</div>
<div>
<br /></div>
<div>
Don't look at this as a once and done annual process. Provide feedback on positive progress... don't be overly critical of your staff. It's a journey, it's not a sprint. Don't expect to change the world, or do this yourself. Get the staff involved, and ask them to help provide feedback, confidentially or otherwise... and encourage team members to provide positive feedback to one another.</div>
<div>
<br /></div>
<div>
If you recruit, develop, and promote in an equitable way... and give credit where its' due... you may find that egos aren't an issue... people don't need to fight for recognition... they get it from the team.</div>
<div>
<br /></div>
<div>
Be humble, if your team succeeds... they deserve the credit! It's your job to be a leader, and the best leaders are often those that recognize that they also are just another team member... whose job it is to help focus resources on what's most important. If you're not sure what that is... well... that's a post for another time.</div>
Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5266891484441380662.post-53323444616744912742013-11-17T22:17:00.002-05:002013-11-18T21:55:39.396-05:00Keep your eye on the prize (and what is that again?)I had a conversation with a staff member the other day. They were providing me an update on their project via email, and the note was very long... and full of technical details. As I read and reread the note, I had to ask myself... were they clear on our objectives? What I really needed to know was... what does this mean to my project... a slight delay... a postponement... or a catastrophic failure?<br />
<br />
In order to understand this a little better... let's say your roof needs replaced. You have two options... you could hire contractor A for a flat $4,000 in labor to replace your roof.... or contractor B, who charges $50/hour. If you select contractor B, and he does the job in 40 hours, and saves you $2000, and the roof leaks... are you happy? How about if he takes 120 hours, and bills you $6,000? That's sounds like a pretty dumb question. What about if contractor B takes 80 hours... and you end up the same $4000 dollars? Then you'd probably think it was fair, if the job was well done.<br />
<br />
That's pretty strait forward. Let's say contractor A sub-contracts this to a local roofer. The roofer works really hard, and it takes him 160 hours... and you get a good job. Now, he had to work 60 hours a week, and missed three of his kids baseball games... and his anniversary... all because he had a deadline. If the deadline was two weeks... are you going to feel bad, or really even care what the impact is to his personal life? Maybe he decided to add a few extra touches, and hand nail the roof vs. using an air-roofing hammer.<br />
<br />
It's not so cut and dried, is it? Your value comes from the fact you feel that $4000 is the right price for a quality roofing job. That's the service you're contracting. You wouldn't think your roof was better if Contractor A's person missed all of their personal events, because it was their choice. They could have used an air roofer, or negotiated a more realistic finish date if they preferred not to use one. Their decision to be a martyr doesn't really garner any compassion from you... because... unfortunately, it didn't make your roof get done in less time than estimated... or add any value directly to you.<br />
<br />
You are judging them on their ability to deliver a quality roof in two weeks for $4,000 or less.<br />
<br />
Project management is the same. You aren't judged on minute details, hours of work, personal sacrifice, providing volumes of data - (e.g. the contractor coming down to let you know every time he finishes a bundle of shingles). Although, if he found he needed to replace some of the wood at an additional expense... wouldn't you want to know up front, or at least as soon as he identified the issue?<br />
<br />
What do customers want, and how will you be evaluated are important parts of project management. They usually include:<br />
<ol>
<li>Accurate, succinct periodic updates on the project progress using terms of "what this means to my customer".</li>
<li>Proactive communications for potential risks, or identification of opportunities.</li>
<li>An accurate achievable schedule, with periodic updates.</li>
<li>Good faith estimates when there is scope creep, and realistic negotiations to accommodate this.</li>
<li>Flexibility with schedules - if it makes sense to change scope, do it in good faith. How would you feel if the contractor chose to cover up the bad wood because he didn't want to spend the additional time, and you had to do a major portion of the roof over. Had he been forthright, the additional costs and effort may be minimal... and you may have been willing to give him more time to complete the expanded scope.</li>
<li>Honest communications.</li>
<li>Ability to account for resource usage on their project. You want to know that if you paid for a resource, he's not working on his friends house... he's really working on yours.</li>
<li>Knowing that they are getting an honest days' work for an honest days' pay.</li>
</ol>
The last comment may sound like common sense... I can tell you that I have encountered numerous people through the years that have a double standard. They wouldn't accept their contractor to bill them while they are not working on their project... yet they do the same. They find ways to pilfer time by extending lunches, coming in later, leaving early. Ironically, you'll usually find that they aren't your best workers... they're usually marginal. That's why they don't recognize that their lack of dedication impacts their output... because they may not be producing that much in the first place. As I've said in other posts... watch the output... it's your best gauge of productivity. If someone isn't dedicated... they probably don't give 100% the rest of the day. Now this may seem like clock watching... it's not. You may find that one of your most productive employees is occasionally late, or needs to leave early... or take longer lunches. What you'll find in that case, most likely, is that he puts in other hours and more than makes up for this lost "clock" time with more productive time. He's also 100% focused on the prize.<br />
<br />
So, I may have rambled a bit... the bottom line... is know how how you're being judged, and then communicate it to fairly judge your staff, and the criteria that all are being judged by... and then deliver results accordingly. Time isn't a fair predictor of productivity... output is much more equitable. That's the bottom line when it comes to effort. If your airline mechanic is a nice guy, works lots of hours and tries really hard... yet doesn't have your confidence, do you really want fly in the plane? Oh... and be sure that you judge yourself by the same criteria you judge others... or better yet, don't judge... objectively evaluate performance. Judgement often includes a bias, that's one thing we already have enough of in our world today.<br />
<br />
So, go... plan, organize, lead, direct, control... and most importantly... deliver!Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5266891484441380662.post-89380697850677128122013-11-17T21:23:00.001-05:002013-11-17T21:31:00.661-05:00Project Management (and child rearing) RulesYou want to be a better project manager, and you think are you are... but those damn customers keep changing the specifications... and they really suck at communicating with your team. Whose fault is this? I'll give you a hint... if you raised great kids, pat yourself on the back... you get part of the credit. The rest is theirs! However, if your kids are terrors... go look in the mirror, and you'll find someone that may be partly at fault... the rest of the fault is ... theirs. Hmmm... either way, you can't take all of the credit, or all of the blame? How is this?<br />
<div>
<br />
Project management is like raising kids. Stick with me as I go through this. </div>
<div>
<br /></div>
<div>
<ol>
<li>Plan for the unexpected: So, you have a few little rug rats... and regardless of your plans.. they seem to have a life of their own, their own opinions, ideas, and like your projects... they don't always turn out perfect. Maybe you shouldn't strive for YOUR vision of perfect... common ground is good.</li>
<li>Negotiate and manage change. Set the rules too strict, and you'll have a rebellion. Set the rules too lose, and you won't get any respect. </li>
<li>Communicate, no really... communicate. Sometimes it's as important for your kids, and your customers to understand why as it is to understand the impact.</li>
<li>Admit when you're wrong. You expect your kids to admit when they are wrong... .the same goes for projects... why nitpick over who is at fault, if time is better spent developing a strategy to get to the desired end state.</li>
<li>Don't play by different rules... everone needs to do their part, communicate well, take ownership, and remain engaged.</li>
<li>Share the ownership... It's not their project... it's a shared goal.</li>
<li>Set limits - agree to deliverables, and if they change, then re-negotiate.</li>
<li>Complement and praise accordingly - both across the team and within your team. You didn't like it in school when you took the blame for someone else, or another took your credit. Follow the same playground rules.</li>
<li>Share ownership... develop a shared vision.... did I say how important it is to share the ownership?</li>
<li>Don't be an ass. Enough said... if you're confused, talk to your kids.</li>
<li>Don't plan minute details years in advance... little bobby may not want to be a surgeon, yet if he's week in science... understand that maybe that's not his best choice for a career.</li>
<li>Know your projects' team limits, and use them as a strength by avoiding weaknesses.</li>
<li>Look for common ground, especially when things go south..</li>
</ol>
<div>
Successful project management is about:</div>
<div>
<ol>
<li>Knowing how to manage projects, the correct techniques and processes.</li>
<li>Understanding there is a human element, and we are built imperfect and will make mistakes.</li>
<li>Constantly probing to understand more about the background and implementation of the project to look for potential risks and opportunities as the project progresses. If you can identify these and address them early, you'll be much more successful.</li>
<li>Project management is also an art... it involves watching and listening for the subtle nuances to understand when you've encountered an opportunity, or when you need to re-adjust to accommodate a new risk or obstacle.</li>
<li>Project management requires... listen for it... a tremendous amount of over-communications. Why "over"... think how much you communicate, then multiply it by something... depending on your audience. AVOID RAMBLING... it adds no value.</li>
<li>Negotiation skills - for every scope that creeps... deliverables, resources, or funding may need to be revisited.</li>
</ol>
<div>
<br /></div>
</div>
</div>
<div>
My wife and I have a wonderful relationship. I'm definitely an extremely lucky man. We've been married for 27 years and every year gets better. We often joke that kids are really hard to screw up... as long as you pay attention. We definitely made our fair share of mistakes... they are resilient.... and you really need to try hard... or neglect them to really screw them up! Projects are the same way... give them the proper attention, care and feeding, and you will succeed.</div>
<div>
<br /></div>
<div>
<br /></div>
Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5266891484441380662.post-13023807332284466202013-11-17T20:51:00.000-05:002014-09-18T13:24:13.810-04:00Tracking Project time in Google DocsI had a recent need to find a new method of doing time reporting against projects and services. My services have different resource commitments, and its important that we show our customers and stakeholders that we are fairly delivering value. Before you make the normal sigh, and under your breath mumble what a waste of time... hear me out!<br />
<br />
Why does it add value? Let's go to the root of the reason why we track time. Is it to hold our staff accountable for punching a clock? No, if you evaluate technology professionals on how much time they spend in front of a keyboard typing, shame on you. Your skills are dated. You should judge a person's contribution based on the value they deliver. Would you pay a mechanic that looks busy for four hours $600 for a basic car inspection when everything passes and no repairs are necessary? No, obviously not. You want some type of value. Judge your information technology by the same litmus. What do I mean? I honestly prefer my staff to spend the same time researching a problem and resolving it with a few lines of code that resolves the root issue... than develop a thousand lines of code that fixes the problem by masking the error. The extra code just adds future maintenance costs.<br />
<br />
Ok, I'm digressing... let's get back to the point...what is the purpose, really?<br />
<br />
<ol>
<li>Tracking time against project and being OBJECTIVE can provide the data you need to improve your project management skills. Are there areas of your projects where you consistently are optimistic and end up behind schedule? </li>
<li>Could it be you need to add a weighting factor... since everything never goes well... and everyone plans for the most optimistic plan... or the most pessimistic plan... instead of the most realistic plan? You learn that factor from looking at your projects, and how well you've met the time schedules.</li>
<li>Do you have one resource that consistently can't meet the time schedules, when others continually are on-time? You may have a training issue that you need to address... or you could have someone who is getting all of the more difficult work? You only know by looking at results.</li>
<li>What is your actual non-project time? You build a schedule based on programming time... how much additional time is spent in meetings, on phone calls, walking through unexpected use cases, out sick, training, vacation, etc.? Tracking helps you figure this out. I reallocate non-project hours against project hours to fully absorb these so I can tell my customers how much time was spent on each of their services. This technique comes from my manufacturing background.</li>
<li>Don't be an idiot. If you track time at an extremely high level to keep things simple, and can't tell other than looking at remaining hours where your project is at... you're not planning correctly. If you can't identify a critical path across the project... other than "TASK A"... you could use some training. I've blogged about this before... check it out.</li>
</ol>
<div>
Now, the solution for a small team. I'm not sure how well this scales, so keep this in mind...</div>
<div>
<br /></div>
I've established a Google Doc. The first parts' pretty simple... I have one week for each person to enter their time against project. Now, for a little more advanced techniques... I want to be able to summarize by service, project, and task. Since I have a smaller team (less than 10), I often have people working together on a project or service. I need all of the summation to be correct and consistent, and it's unfair to ask everyone to type in the service, project, and task names identically. So I've created a list of projects that my staff and I can maintain as a lookup. Also, as a quick trick - you'll see red cells on the sheet that say "insert between here". This is so total areas grow automatically to include new data when things are between the red lines. You'll see what I mean... my formulas don't go from the first to the last number that should be added... they go to the red cells instead (Check out Fannie's tab in the Google Doc example below).<br />
<br />
Here's a few more tricks for you:<br />
<br />
<ol>
<li>Data validation - you can create a tab that has a list of valid choices so that all of your projects must be from the master list. Check out Fannie's tab for the projects she reported time against... or try it yourself using the menu selection Data -> Validation.</li>
<li>VMERGE - what a cool llittle script - VMERGE allows you to get pull from multiple sheets, and put it in a single tab so you can analyze it. You activate the script by going to Insert -> Scripts... and then type in VMerge. You can also check out the linked documentation. For a larger team, you may want to investigate the importrange function to see how well it scales.</li>
<li>Query function. I've used SELECT, SUM, and GROUP-BY through-out the spreadsheet. It's very SQL-Like - I opted to use column letters so as my sheets grow, I don't need to redo the formulas.</li>
<li>Where-ever it makes sense, Google Docs appears to allow columns instead of cell ranges. This adds flexibility. Check it out for yourself.</li>
<li>PivotTables - they are a great way to portray information as long as they can be predicted or controlled (rows vs. columns). In my sheet, I opted for the most part to stay away from these... since my projects were limited and I wanted more granular control of my summary data.</li>
<li>Conditional formatting - Right click on selected cells - and select conditional formatting. In my case, under 40 hours has a red background... and over forty has a green background. Again.. check out the formulas within the totals on Fannie's page.</li>
</ol>
<div>
<br /></div>
<div>
So, what does it look like?</div>
<ol>
<li>Employee entry: <div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-xvCCLC3Nhbs/Uolvtd_H5AI/AAAAAAAAADA/TlWgD5prLiU/s1600/FannieTimeEntry.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://4.bp.blogspot.com/-xvCCLC3Nhbs/Uolvtd_H5AI/AAAAAAAAADA/TlWgD5prLiU/s400/FannieTimeEntry.PNG" height="171" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
</li>
<li>Employee summary:</li>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-_0ctHdSZN4Y/UolwKqW0XgI/AAAAAAAAADI/9-6I9CQzsdc/s1600/EmployeeTimeSummary.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-_0ctHdSZN4Y/UolwKqW0XgI/AAAAAAAAADI/9-6I9CQzsdc/s1600/EmployeeTimeSummary.PNG" /></a><span style="text-align: left;">3. </span></div>
</ol>
Summary report:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-tMVS6gEr76I/UolxWVmNMhI/AAAAAAAAADU/_uVtxKYsCPs/s1600/SummaryTime.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://4.bp.blogspot.com/-tMVS6gEr76I/UolxWVmNMhI/AAAAAAAAADU/_uVtxKYsCPs/s400/SummaryTime.PNG" height="336" width="400" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<br />
<div class="separator" style="clear: both; text-align: left;">
I've posted the generic spreadsheet so you can check it out... <a href="https://docs.google.com/spreadsheet/ccc?key=0Ag8WlpBJykv0dHdOZF9zN1FtelJLWTlaN1FKalNDd2c&usp=sharing">https://docs.google.com/spreadsheet/ccc?key=0Ag8WlpBJykv0dHdOZF9zN1FtelJLWTlaN1FKalNDd2c&usp=sharing</a></div>
<br />
<div class="separator" style="clear: both; text-align: left;">
I'll cross post this on my excel blog. Also, if you find you have some trouble with your projects, and you want to learn more... check out my prior posts. Sure, there's some dry humor... what do you expect? I usually write this stuff late at night when I can't sleep!!!</div>
<br />
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<br />
<div class="separator" style="clear: both; text-align: left;">
If you have specific questions, leave a comment, and I'll get back to you!</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Thanks!</div>
<br />
<ol>
</ol>
<div>
<br /></div>
Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5266891484441380662.post-26074242941976436112013-10-03T23:50:00.000-04:002013-10-04T00:07:29.332-04:00Hire the right person!It's critical to focus on hiring the best candidate. Everyone brings something new to the table... that's how organizations grow. When we hire clones, or have a fear of hiring someone who has stronger skills in a specific area than we do, we limit our teams' growth potential. When we maintain that raised bar, we can eventually find and attract talent that contributes to the growth of a team. Hiring a great candidate is a lot of work, and takes a great deal of time. Hiring a poor candidate has little upfront cost, but oh... the challenge of holding them accountable takes many times more effort that one who is competent... and has a major negative impact on your team dynamics and personality. It's important to engage the team in the hiring process, this is a good opportunity to get their feedback on a candidate's technical skills, and organization fit. Don't settle, hire smart.<br />
<br />
We need people that can bring independent perspectives to a discussion, and provide contrasting opinions. Everyone has certain strengths, and weaknesses. As part of employee development it's critical to invest in not only development of technical skills... we need to provide stretch opportunities, as well as feedback on improving communications and presentations skills for different audiences, managing projects, taking ownership, and being customer focused. It's not a me thing... it becomes a we thing - and a team competency. The team becomes engaged in improving one another, providing peer feedback, and become active in the continuous improvement and growth of the team.<br />
<br />
Hiring people that are weaker may seem like a smart path to job preservation. However, it's not. Hiring extremely intelligent independently motivated people that have a good skills foundation... that are willing to learn and share, and that can be counted on to do the right thing is definitely the smarter choice. They may initiate more difficult conversations because they may challenge existing processes and direction. However, this can lead to the further growth of the organization. Leadership isn't about taking the easy path... it's about setting the right tone and direction.<br />
<div>
<br /></div>
Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5266891484441380662.post-7767337357555877512013-10-03T12:00:00.000-04:002018-01-20T11:07:42.966-05:00Technologists - Go learn a second language - English!!!<h1>
Communicating on the same level...</h1>
In the technology field, I'm often amazed how many people think that the more words they can say and the less others can understand, the more intelligent they sound. This can be used to mask discomfort with normal conversation, a lack of knowledge of a subject, or an inability to read the non-verbals from your audience. It definitely is not leaderly behavior, and should be discouraged.<br />
<br />
I'm convinced that for a non-tech, it's often like trying to understand someone that knows spanish, and is looking for a place to buy an apple in New Jersey. Sure, there are others that know spanish around. However, they aren't always there to translate. What does the visitor from Spain do? They learn enough english to be able to communicate with the kind folks in Jersey so they can find a grocery store, and get their apple.<br />
<br />
If you're not in an exclusively high-tech industry... look around... what's the common language for your community? Technobabble, or business speak? I've worked for high tech companies, and the common basis for all their staff wasn't technobabble, it was common english. I've seen the same through-out my career, english is the language of business... and acronyms and technical speak create confusion when they are used unnecessarily.<br />
<br />
I've also been known to play oblivious to have a job candidates talk themselves into a corner, and then ask a candidate the business impact of that groundbreaking technology they just name-dropped, since I "don't quite understand it". Wow, to hear them connect this with some business requirement would be a stretch. In many cases they couldn't go beyond their initial name-dropping expected to wow an interviewer. We've trained our recruiters to look for keywords, and not understand the context... and in turn we then reward an interviewee with a job they may not deserve unless we remain diligent in interview analysis.<br />
<br />
I'm as comfortable speaking and explaining technology with a business executive as with a technical staff member. I have learned long ago that bridging this gap allows for better alignment of business with technology. Is it perfect? No. When someone pretends to understand what I say... I may not properly read that I need to synthesize this further. This can be especially true if I believe I'm communicating with someone extremely technical, who may not be familiar with a concept I'm discussing. Technical people are more likely to pretend to know something than ask for more information. Anyone that knows me knows that I have no problem asking for an explanation for something they've mentioned that's new or I don't understand... and they should feel the same way. That's how you create a learning culture.<br />
<br />
One example of bridging the gap came early in my career. A company I worked for lost a senior accountant during fiscal year end closing. One of the VP's came to me, since I'd been rewriting portions of a custom developed fixed asset depreciation system they'd purchased. The software didn't properly implement asset depreciation with <a href="http://en.wikipedia.org/wiki/MACRS" target="_blank">MACRS</a> vs. straight line vs. double declining balance depreciation. I was "volunteered" for a one-time assignment to manually calculate depreciation expense for the year. The VP had to explain things that would be common sense to a true accountant... such as the correct life for new assets, and differences between book and tax value. I reconciled the fixed asset listing with the asset values, depreciation expense, and accumulated depreciation for the individual general ledger accounts. It was an interesting experience.<br />
<br />
It's experiences like this that taught me that the more we are approachable, and willing to learn, the more value we can add. I can tell you that after that initial year of manually calculating depreciation, the fixed assets program became extremely reliable. It even validated the accountants' input to ensure that the years assigned were valid for the type of depreciation method selected.<br />
<br />
As technology leaders, it's our job to bridge the gap. We would consider it rude for someone that speaks Spanish and then becomes frustrated by the arrogance of the locals not understanding their language. However, if we don't try to bridge the gap, we are doing a similar thing!<br />
<br />
So, try something new... learn and practice a new language... English. You may be surprised how far it takes you!<br />
<br />
<br />Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5266891484441380662.post-65747415003091981032013-08-28T22:51:00.000-04:002013-08-28T22:52:46.346-04:00The Importance of Confidence in ResponsesI once worked for an aggressive, brilliant CEO that explained this best. He asked me a question during a senior management meeting, and I responded... "Well, sir, I think...". He paused, removed his glasses, then adjusted his posture. He responded that I wasn't paid to think, I was paid to know... and it was my responsibility as a leader to be both confident and honest with my responses. If I wasn't sure, admit I didn't know... and later provide an answer that I could state with confidence. <br />
<br />
He went on to explain he'd rather hedge a critical business decision against an unknown risk, than to inaccuratley assume he knew the risk based on potentially flawed information. He reminded me this was a learning opportunity, and one which he did not want to see repeated. It was an interesting "pause" in an otherwise active meeting. <br />
<br />
This has stuck with me... and I've applied it to many decisions in my career, and my life. It's better to admit what you don't know, than to make a decision based on an incorrect assumption of fact. If you can't provide an answer quickly with a high degree of confidence, then offer to research and provide an accurate answer. I respected him for this learning opportunity. I've long moved from the organization. However, the valuable lessons I've learned have continued to influence my actions.Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5266891484441380662.post-36967346537415163552013-08-13T21:25:00.001-04:002013-08-18T23:38:35.101-04:00College Prepares you for LIFELONG LEARNING, NOT LIFELONG EARNING!Think about your college education... what do you remember most? Was it a formula used to calculate current or quick cash flow ratios? How about calculating the net present value of an annuity, or what the "rewind command" means in Fortran 77, or what a z-test is used for? Or was it the research paper that frustrated you because it was loosely defined, and you had to actually think for yourself?<br />
<div>
<br /></div>
<div>
I want to be brutally honest... college is about BUILDING FOUNDATIONS. Learning is not a point it time accomplishment, it needs to continually evolve. If you believe that by spending two, four, six, or eight years in an institution of higher education, you've written your ticket for lifelong earning... you're sadly mistaken... you OWN your career... not your employer.</div>
<div>
<br /></div>
<div>
You are paid based on the value you provide to an organization, sometimes measured by improved efficiency, increased sales, improved profits, by building more widgets, or possibly.... you have the same last name as the owner, and it's easier to pay you than just give you money. When you fail to contribute in a positive manner, you are no longer of value to the organization. You own this responsibility, not the organization.</div>
<div>
<br /></div>
<div>
I'm amazed as we interview people how few really take ownership for their career. They believe college initially prepares them, and that each of their future employers should train them in new processes, techniques, and ensure that they remain marketable and competitive. When their skills aren't sharp, it's someone else's fault. What would happen if nobody innovated, learned new methods, new manufacturing techniques, new design processes, etc.? The company would disappear, and there would be many staff that could not easily find a new job with their skills... and that complain that the "old company" failed them because it was unable to keep up and that their careers were short changed.</div>
<div>
<br /></div>
<div>
There are situations where this occur... and that's sad, these are short sighted companies that normally don't last long. If there were a few people willing to take risks, and invest some of their personal time... the story could change dramatically. The organization could move from a company that lacks focus and vision, to one that looks for continuous improvement and takes calculated risks in order to continually improve and grow.</div>
<div>
<br /></div>
<div>
So, next time someone asks you what you've learned recently... think hard... and be honest with yourself. Seek opportunities to learn, engage your employer... find funding... find small projects to test your ideas and succeed... and really listen. </div>
<div>
<br /></div>
<div>
I've found that the best ideas often come from line staff that nobody will ask. These are the blue collar workers on the assembly line... they carrying the burden and blame when quality suffers, or productivity drops... yet they are not often asked directly what can be done to improve their processes or the products they create. Out of necessity, these people usually have broad "hands-on" skills that they can leverage, or knowledge from another area they can apply. These staff can be extremely innovative people that have learned to build houses, repair cars, and continually learn in order to be able to afford every day life. They don't have the option of calling someone and saying when can you get this done?</div>
<br />
<div>
So, take control of your education, and ownership of your job... stretch... and reach outside your comfort zone... innovate... share... learn... and grow. College didn't teach you to be lazy, life is a moving target, and sometimes it's tough. Put on a helmet, focus, and become engaged!</div>
Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5266891484441380662.post-5228609597868617512013-08-07T23:15:00.004-04:002013-08-07T23:15:37.891-04:00Ready, Set,... GO LIVE!!!!Well, you've spent the past eighteen months working on your project... you've spent a tremendous amount of resources ensuring that your project will be ready for release... potentially to see it fall apart within the last few weeks... why?
Well, it's most likely because you didn't put together a go-live plan.<br />
<br />
Your project plan was focused on ensuring you've met the your customer requirements... and you've had sufficient details in the plan to get your product delivered... on time.
The devil is in the details. I work for a large university, and there is a complex requirement to introduce new production services into our environment. We actually have four development environments, and our projects move through these, which include...<br />
<br />
<ol>
<li>The local developer machines - developers control these so their status at any time could include a mix of code at different stages in the release cycle.</li>
<li>Shared development environments which are in a more controlled state, with releases normally coordinated by project leads.</li>
<li>Locked down acceptance environment. These are controlled by a different infrastructure group, and in order to be updated, would require instructions, and a self applying patch script. Code reviews are normally in place prior to releases in this environment, with coordination and hand-off by a project lead.</li>
<li>Locked down production environments. Once the scripts have been proven on acceptance, the same scripts are executed by infrastructure teams on production, during a maintenance window, with developers verifying the update was applied successfully to each server.</li>
</ol>
So, what do you include in your go live plan? That depends on your environment. In addition to the above migration strategies, we often are required to ...<br />
<br />
<ul>
<li>Document the deployment process, requirements, and any special needs.</li>
<li>Document the performance profile, and requirements including storage performance. </li>
<li>Provide pre-packaged updates.</li>
<li>Document security requirements.</li>
<li>Identify service name, and any necessary Verisign or Comodo certificates.</li>
<li>Request DNS entries to support the new service.</li>
<li>Identify firewall rules, and ports necessary to support the service.</li>
<li>Request setup of any remote monitoring.</li>
<li>Identify the maintenance windows.</li>
<li>Test and submit any data integration processes, or other periodic maintenance processes.</li>
<li>Perform necessary vulnerability scans on the servers to verify that only necessary ports are open, and that critical patches have been applied.</li>
<li>Perform any applications scans to verify that you've addressed sanitizing rules to prevent cross site scripting and SQL injection.</li>
<li>Test the application in each of your environments.</li>
<li>Ensure that each page of your application verifies that sessions exist, and that you have a solid method for authentication. (Common include files or master pages help with this.)</li>
<li>If you have external logging, ensure that it's in place.</li>
<li>Identify your backup frequency, rotation, snapshot process, and any replication.</li>
<li>Complete a disaster recovery plan, based on the requirements of the service.</li>
<li>Have support trained, and in place to help users if they encounter issues.</li>
<li>Have a period of open testing where your customers can test and provide feedback.</li>
<li>Have a method to capture support requests, and forward them to a support group.</li>
<li>Have escalation process in place for critical support issues or outages. </li>
<li>Ensure you have antivirus in place as necessary.</li>
<li>Line up and engage staff to develop training and documentation, and determine a method to deliver this in a cost effective manner.</li>
<li>Obtain sign-off from any data stewards that may control the access to data you are delivering.</li>
<li>Detail the final steps of turnover, and ensure that everyone agrees and can meet the expecations.</li>
</ul>
After you go through the go-live process, I recommend doing a postmortem for the project to look for any gaps, and then find ways to continually improve your process. You owe it to your customer.<br />
<br />
So, get in your running lane... line up on the blocks... ready... set... deploy!<br />
<ol>
</ol>
Unknownnoreply@blogger.comtag:blogger.com,1999:blog-5266891484441380662.post-86344041073242083432013-07-30T00:27:00.000-04:002013-07-30T00:28:17.930-04:00Great companies have great marketing... does your team?<div>
Everyone wants to get ahead, correct? What better way than to promote yourself? That depends on your lens or perspective. I'm from a blue-collar family, where humility is regarded as a positive value... and well boasting... is usually reserved for fishermen and hunters. Those that do, let their actions speak... and those that can't... well... spend more time speaking than doing.</div>
<div>
<br /></div>
<div>
Does it always work, probably not... there are times when we each need to stretch outside your comfort zone. I've always envisioned the role of a good manager as one that promoted the efforts of their team, and gave recognition to where it was most earned, by those that do the work. I'd prefer to market team successes than any individual accomplishments. The reality is that any success of the team are a result of the efforts of the team... and any failures... well... often they are a failure of leadership. I'll have to do a future post on what is leadership... it's not management... leadership is painting the target on the wall and getting people to follow you... management is controlling how we get to the destination..</div>
<div>
<br /></div>
So, back to the question at hand... what is marketing... and why is it important in technology for companies that do internal IT? It's a question that most people ask themselves. For that answer, let's discuss what marketing is not...<br />
<div>
<ol>
<li>It's not overstating what you've done, what you can do, or what you're capable of doing.</li>
<li>It's not committing to something you can't deliver, are incapable of delivering, and have no plans to deliver.</li>
<li>It's not lying, stretching, or stating things that cannot be achieved, or trying to get a foot in the door when you hope that like a tick, you can't be pulled once you're hooked in and get some blood.</li>
</ol>
<div>
<br /></div>
</div>
<div>
What is marketing? It's a necessary skill that you need to learn in order to survive. Just because you're an internal resource doesn't mean that you should not be prepared to compete with other teams or external organizations for projects. It's important to be prepared to provide a plan to get and service a new customer, or to maintain an old customer. There's this small thing that's been happening in IT... it's called outsourcing. There's always someone smarter that can do things better... if it's not you... it will be someone else.</div>
<div>
<br /></div>
<div>
Case and point... see the cartoon below... it was developed using tools from ToonDo.com, and was delivered as an icebreaker at a recent meeting. It was an overwhelming success... it helped demonstrate that we had some basic sense of what their challenges, goals and objectives were for a project in a context that was understandable... and important to our customers.</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://3.bp.blogspot.com/-yAUD33-9toc/Ufcyr-r72pI/AAAAAAAAACY/hTj4RWO1Uew/s1600/PSCSComic.gif" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="304" src="http://3.bp.blogspot.com/-yAUD33-9toc/Ufcyr-r72pI/AAAAAAAAACY/hTj4RWO1Uew/s400/PSCSComic.gif" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Connecting with your customer!</td></tr>
</tbody></table>
</div>
<div>
We've made significant efforts moving from older technology to a new ASP.NET stack adopting object oriented technology, implementing user controls that could inherit properties from their parents when dragged onto a form... and that handled their own methods to update the associated data. My team had also abstracted the database into business objects as well. This new effort included a dynamic workflow engine that included versioning to support future workflow changes that may need to be introduced... and was designed to be able to match workflows at different hierarchical levels of granularity. We also heavily adopted templates, environment variables, and other "soft" ways to update the application without changing code.</div>
<div>
<br /></div>
<div>
Our partners are going through some major changes, and want to evaluate other solutions... partially because one of our highly adopted systems was written almost ten years ago... and doesn't have the flexibility of the new architecture. If we want to be at the table and in the discussion, we need to ensure that our customer is judging us on our current projects, not one that is a legacy project.</div>
<div>
<br /></div>
<div>
Through demonstrations, and connecting with them on a business level, we've allowed our new solution to continue forward in the evaluation process. Will it be chosen? I don't know... that will really be a business decision. However, it should be a decision based on an equal footing... not one that is from lopsided from a lack of marketing on our side. Making this assumption, in my opinion... would be nothing more than a significant miscalculation.</div>
<div>
<br /></div>
<div>
The moral of the story... don't become a dinosaur, learn, innovate, and continue to compete. Don't become stagnant in your technology, or complacent... and for the sake of your projects.. sometimes all you need to do is guide.. and then get out of the way! If you focus on recruiting great people, develop them, and make sure they are recognized... they will want to succeed... have ownership... and a sense of pride. The will develop great products... sometimes it's your role to ensure they have the knowledge, skills, and tools they need... remove any obstacles, and let them succeed! Guide the project... there's nothing that kills a project quicker than scope creep... </div>
<div>
<br /></div>
<div>
Don't let the below be said of you... for everything you add to a project, look for something of equal weight to remove, or extend the timeline immediately... you should NEVER hear....WHAAAATTTTT?!?! YOU'RE GOING TO BE A YEAR LATE?!?!? AND YOU BLAME IT ON ME CHANGING SCOPE!?!? YOU ARE INCOMPETENT... YOU DIDN'T CAPTURE THE CORE REQUIREMENTS IN THE FIRST PLACE!!!!...</div>
<div>
<br /></div>
Unknownnoreply@blogger.com