tom lamm pmp, pmi-acp

What is a Blockchain?

September 18, 2018September 18, 2018
by tom lamm

What is a Block Chain?

A blockchain is distributed ledger of transactions that cannot be (easily) altered and is verifiable by all participants. Every recorded transaction is shared and verifiable so all participants can agree on the authenticity of each transaction.

“First and foremost, Blockchain is a public electronic ledger that can be openly shared among disparate users and that creates an unchangeable record of their transactions, each one time-stamped and linked to the previous one. Each digital record or transaction in the thread is called a block (hence the name), and it allows either an open or controlled set of users to participate in the electronic ledger. Each block is linked to a specific participant.” (Mearian)

Distributed. All participants see every transaction in the ledger, so all agree on the validity of each separate transaction or block.

Verifiable. Each transaction is a block. Each participant has a history of transactions, or chain of blocks, connected through a set of cryptographic keys, that tie the chain together. Once created, no individual block may be altered without breaking the chain in a way that is automatically detected by the other participants.

Participants. A participant is a member sharing the ledger and possibly participating in transactions. The transactions can be monetary, such as a cryptocurrency, or any other form of transaction. Networks of devices such as the Internet of Things (IOT), a smart energy grid, or a complicated supply chain are only a few of the potential uses of a blockchain.

A Simplified Example

Imagine a room full of traders using a shared currency (eCoins) that they mutually maintain. They decided to eliminate the need for a bank and to manage their own currency. Each has some currency on hand, some have goods to sell, others are wanting to buy. To manage the currency, they must have a way to verify every participant’s balance. To do that, every exchange of currency is shared with each participant.

Bob buys something from Sue for 35 eCoins, everybody gets the notice that Bob just paid Sue 35 eCoins. Sam exchanges US dollars for eCoins with Sue at the rate of 0.75 eCoins per Dollar. Sam pays Sue $200 and receives 150 eCoins; everybody gets the notice that Sue just paid 150 eCoins to Sam. Nobody has to know why the payments, but they do know the amounts and participants in each transaction. This guarantees each transaction; if the payer does not have the eCoins required, the transaction will not occur.

In addition, a small group of these participants do extra work. They double-check the validity of each exchange. After the Sue pays Sam 150 eCoins, they double check the transactions in Sue’s transaction blockchain to ensure that she actually has the 150 eCoins she claims to have. These verifiers receive a small amount of eCoins in exchange for their extra efforts.

Replace that room with the internet, the ledgers with blockchain software, and this is a very simplified description of how cryptocurrency works.

Obviously, this group’s efforts to replace a central bank and manage the currency themselves means that they expend a lot of effort maintaining the ledgers, duplicating and sharing the transactions, and verifying to double check that everybody is honest. This is only possible through the use of highly efficient computers to handle the transaction sharing, calculations, and verification.

Not all blockchains are used for cryptocurrency. Replace “cryptocurrency” with “electricity” and “people” with “meters” and you have a chain of reporting devices on a smart energy grid. Or, use “shipping containers” and “carriers” and the chain supports a complicated supply chain.

Practical Uses

A Forbes magazine article titled, What Is Blockchain And What Can Businesses Benefit From It? suggested the answer, “… [businesses] which possess the following traits: Transaction-based; Benefits from public scrutiny; Benefits from history [ledger] that can’t be rewritten; [and] Decentralization benefits the end user or customer.” (Iinuma)

Any business process that depends on a shared, highly reliable, transaction ledger can potentially gain from blockchain technology. Cryptocurrency was the obvious first use, but the advantages of a shared ledger of transactions is not limited to financial information. Many networks of devices monitoring or controlling decentralized transactions can benefit from blockchain technology.

Consider a smart power grid with some participants using power, some generating power using wind or solar, and others doing both. The MIT Technology Review describes this collection of electricity users and providers as “a byzantine system [that] racks up transaction costs, while leaving plenty of room for accounting errors…”. They go on to suggest, “What if the meter wrote data directly to a blockchain instead? Most of these problems would vanish at a stroke…” (Orcutt).

Another example is a complicated supply chain. IBM and Maersk are launching TradeLens, a pilot blockchain project to support supply chains. Reuters reported, “Shipping group Maersk (MAERSKb.CO) said on Thursday [August 9, 2018] 94 companies and organizations have so far joined a blockchain platform developed with IBM (IBM.N) aimed at boosting efficiency and limiting the enormous paper trail of global container shipping.” (Reuters). Their goal is to help manage the supply chain from end to end, increasing efficiency and reducing paperwork and bureaucracy.

Like many innovative technologies, the creative ideas about how to use this new technology are yet to be discovered. Some will be truly disruptive and market changing, others will simply improve an ongoing system in ways that the end users may not be fully aware of at all.

Smart Contracts

Blockchains are also used to create Smart Contracts. Details of Smart Contracts are beyond this brief overview, but in short, they are a computer based contract that can execute automatically depending on pre-set conditions. For example, a Smart Contract between several parties could execute one or more financial instruments or issue an order to ship a commodity based on market conditions or the actions of the signatory group.

It is important to know that smart contracts have a history of problems, partly because they are new there is little experience with them.

In The Truth about Smart Contracts, Jimmy Song summed up the second point, “Consider that writing normal contracts takes years of study and a very hard bar exam to be able to write competently. Smart contracts require at least that level of competence and yet currently, many are written by newbies that don’t understand how secure it needs to be. This is very clear from the various contracts that have shown to be flawed.” (Song)

In a Forbes overview of the value and shortcomings of smart contracts, Sherman Lee described part of the problem, “Looking at the numbers, one might take Ethereum’s 3% smart contract failure rate as a tolerable loss, a proverbial drop in the ocean. Yet, when a safeguard fails to protect billions of dollars worth of currency, bad things can happen.” (Lee) Lee goes on to describe the upside and suggest ways to secure smart contracts.

Fully understand the value and shortcomings of smart contracts before entering into one.

Is Blockchain Technology Right for Your Business?

The answer, of course, depends on the industry and your specific business. The IT group must consider the business strategy, evaluate risks, costs, value, and return on investment. For instance, while it may be possible to add monitoring equipment that uses a blockchain to record progress through the stages of a manufacturing process, a simpler solution may provide the same information for much less cost. On the other hand, using an automated blockchain to track that process from end-to-end may be the best, or only, means available to provide the information required to keep a complicated process running at peak efficiency.

Marketing may be the motivation. Some businesses may soon need to establish blockchain expertise to be considered competitive. Even if the business analysis proves that the return is low, the marketing reality may be that without some demonstrable blockchain expertise, the business will be the equivalent of a buggy-whip provider at the start of the automotive era.

Like any other strategic business decision, knowing the costs, expected return, and value (both tangible and intangible) is the basis for deciding whether this new technology is what you need right now, or something to “keep an eye on” for the future.

References

Mearian, L. (May 31, 2018). What is blockchain? The most disruptive tech in decades. Computerworld. Retrieved from https://www.computerworld.com/article/3191077/security/what-is-blockchain-the-most-disruptive-tech-in-decades.html

Iinuma, A. (Apr 5, 2018). What Is Blockchain and What Can Businesses Benefit From It? Forbes. Retrieved from https://www.forbes.com/sites/forbesagencycouncil/2018/04/05/what-is-blockchain-and-what-can-businesses-benefit-from-it/#6a34b76d675f

Orcutt, M. (October 16, 2017). How Blockchain Could Give Us a Smarter Energy Grid. MIT Technology Review. Retrieved from https://www.technologyreview.com/s/609077/how-blockchain-could-give-us-a-smarter-energy-grid/

Reuters Staff. (August 9, 2018). Maersk, IBM say 94 organizations have joined blockchain trade platform. Reuters. Retrieved from https://www.reuters.com/article/us-shipping-blockchain-maersk-ibm/maersk-ibm-say-94-organizations-have-joined-blockchain-trade-platform-idUSKBN1KU1LM

Song, J. (June 11, 2018). The Truth about Smart Contracts. Medium. Retrieved from https://medium.com/@jimmysong/the-truth-about-smart-contracts-ae825271811f

Lee, S. (July 10, 2018). Blockchain Smart Contracts: More Trouble Than They Are Worth? Forbes. Retrieved from https://www.forbes.com/sites/shermanlee/2018/07/10/blockchain-smart-contracts-more-trouble-than-they-are-worth/#ce4fb6b23a60

Program Management

Measuring Value in IT Applications

January 28, 2018January 28, 2018
by tom lamm

Measuring Value in IT Applications

Tom Lamm PMP, PMI-ACP

The value of a software application is one of the most important of critical success factors, but in practice, one of the least measured. This is especially true of custom applications. Too often, businesses that would never think of making an equipment purchase without considering cost, value, and ROI will design, create, and implement a software solution without knowing how much value the system returned for the cost. Glaser (2009) describes the problem, “Rarely do organizations revisit their IT investments to determine whether the promised value was actually achieved.”

When purchasing packaged software, the value and ROI (return on investment) are considered from the outset. Evaluating a software purchase includes considering the product’s features and deciding which are required, nice to have, and unnecessary. If the product has too many features that are considered unnecessary, the purchaser may seek an option with fewer features and a lower cost, thus obtaining a better ROI.

The same considerations are often ignored in custom software. Value is often considered during design, and then ignored from that point on. Software projects are often evaluated using only two critical success factors: completed features and on-time delivery. The actual value returned for the investment is not on the list.

Measuring Software Value
Software value is measured by the financial gain it provides. It may be a report that provides more efficient analysis of information, an improvement to a process that increases the throughput of that process’s value-chain, or an improvement to call center software that decreases average talk time. The financial gain of each of these examples can be accurately measured and resulting ROI for the improvement calculated. Adding ROI to the list of critical success factors is a far more accurate measure of success than simply considering features and on-time delivery.

Project Management and Value
Traditional project management techniques can be very successful in delivering value, but it is not inherent to the process. In contrast, Agile project management considers value throughout the entire project. At the outset, the founders of Agile software management identified 12 principles, the first principle is “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” (Beck et al. 2001). The emphasis on value is inherent to Agile project management. Agile techniques restrict the work to only features that return value and use value as a primary factor when prioritizing features for development.

Value as a Measure of Project Success
Whether purchasing packaged software, or creating software using traditional or Agile techniques, it is vital to measure the resulting improvement. Determining ROI for software is just as important as it is for any other long-term investment.

Reporting that measurement helps the development team focus on cost and value, improving the resulting ROI. Glaser (2009) even suggests, “In addition to go-live parties, organizations should consider business value parties—celebrations conducted once the value of the project has been achieved”. Whether or not an actual party is involved, recognizing a project team that produced and delivered software that is of high value emphasizes the importance of considering value throughout the development life-cycle. And, doing so helps the development staff improve their delivery of value over time.

References

Glaser J. (July 2009). Strategies for Ensuring an IT Project Delivers Value Healthcare Financial Management 63 (7), 28.

Beck K. et al. (2001). Manifesto for Agile Development. Retrieved from http://agilemanifesto.org/principles.html

Overheard at the Project Management Cafe

From the PM Cafe–Team Leadership

September 19, 2017
by tom lamm

Stacy and Bob were discussing various Agile methodologies when Jim slid into the booth, “Hey good morning you two!”.

“Morning Jim, how’s Saturday treating you?”

“I’m doing great, bad news for my team, they have to work today”, Jim replied, taking a bite from his doughnut.

Stacy looked at Jim and said, “Jim, if your team is working on a Saturday morning, what are you doing here?”

“Oh, my project status and reports are all taken care of, it’s the software coding that’s behind, they can work on that without me.”

Bob replied, “Maybe, just maybe, if you buy two dozen doughnuts and leave right now, you stand a chance of having a team when you make it to the office.”

“What, you think those guys will walk out and resign or something? Hey, it’s unfortunate, but we need to make up some time. They’re professionals, they understand.”

Bob said, “Of course they won’t resign over a little overtime. And, of course they will remain a team. The question is: ‘Will you still be on that team?’ When the going gets rough, the first thing you need to do is make sure that you have the team’s back.”

Stacy added, “You’ve been in their shoes before, how would you feel.”

Jim, dropping his doughnut and heading to the take-out counter, “Oh crap, I never thought of it from their perspective. I look like a total heel.”

Jim, smiling to Stacy, “Not the word I would have picked, but probably cleaner.”

Uncategorized

Thinking About That Internship Program?

July 27, 2017
by tom lamm

Jim joined Susan and Stacy at the Project Management Café just as Susan was saying, “… so they are thinking of starting an intern program.”

Stacy responded, “That can be a great way to develop staff, and it gives some students quality real world experience, and …”

Jim interrupted, “… and they work for free!”

Stacy admonished him, “Whoa there, before you think you’ve found a free labor pool, you’d better talk to HR. You need to know the laws before you find yourself in trouble. Besides, think about it, what kind of work do you expect to get from a highly skilled intern that isn’t paid?”

Jim replied, “If it were me, that would get very old, very fast. Before long, I’d be just putting in time.”

Just as Bob joined the group, Susan asked, “Well, nobody at my office is talking about unpaid interns, but we are asking ourselves how to build the program.”

Stacy said, “We hired one intern to start with, not free, but not highly paid to be sure. She worked during the breaks. We’ve hired some that were able to work during the semester as well. Actually, we’ve come to rely on the extra staff during the summer break.”

“Don’t expect much at first,” Stacy added, “They are not seasoned employees after all. If they start during a one or two week break, give them a light task that they can complete in that time. Let them get to know you, then give them something more challenging during the longer breaks.”

Bob jumped in, “When somebody works out really well, ask them to recommend others.”

Susan, thinking out loud, “So, you’ve got this inexperienced talent coming and going, working part time, sounds like a pain for management.”

Stacy answered, “True, you must respect their schedules. Remember, you are the second job, their day job is working toward their degree. You’ve got to respect that. If they are working part-time during the semester, expect to give them time off during mid-terms and finals. And, when they are working over their vacation, they might want some time for family as well. On the other hand, if you treat them with respect, they can become a valuable employee.”

Susan answered, “That’s what we found so attractive about the idea. We like that we can really get to know the individual before deciding whether or not to make a long term offer.”

Stacy added, “Reach out to any contacts you have at the local colleges and universities. Find contact information on their web sites. Once you have it in place, a good intern program is a great way to supplement your team.”

As they were getting ready to leave Susan said, “Well, it sounds like, with a bit of work and some understanding, we could build a good intern program. One that helps with staffing without the normal interview, hire, and hope, process.”

On the way out, Stacy replied, “You can not entirely replace the traditional interview process, especially for positions that require experience. But, for the entry level positions, an internship program can provide a very good return for the time invested.”

Overheard at the Project Management Cafe

Protect the Project, Protect the Team

July 14, 2017
by tom lamm

Susan joined Stacy and Bob at the Project Management Café. “I am so frustrated with this project. My staff keeps getting reassigned to other priorities and I can’t count on having the resources I need from one week to the next. My schedule is going to ‘heck in a handbasket’ as my Mom would say.”

Bob passed her a croissant, “Tell me about the company.”

“It’s a small company with a limited staff. I understand that management needs to focus on all of the tasks and priorities, not just mine. And, they need to deal with the occasional client crisis when it comes up. But, I’m responsible for this project’s schedule, and can’t always count on having the people I need.”

Stacy answered, “Sounds like a Matrix Organization, a small one, but definitely matrix oriented.”

Susan asked, “Matrix, what do you mean?”

Bob replied, “Think of a spreadsheet, with the tasks and projects as the rows, and the different departments as the columns. So, your project is a row, ongoing maintenance tasks is another, a client crisis becomes another. The columns depend on the company, but they could be development, financial, marketing, etc.”

Stacy joined in, “The staff answers to the managers responsible for the rows, but also to their department. So, when another row becomes a priority, they might be re-assigned to deal with that, leaving your project for that time.”

Susan replied, “That sounds like a good description, but how can I plan any kind of realistic schedule with the shifting priorities?”

Bob, “In a larger organization, there is usually enough staff to be able to dedicate a team for the duration of a project. In a smaller organization, you’ve got to negotiate and share resources. Have you thought about using sprints?”

Susan asked, “Sprints? That’s an Agile, Scrum, methodology, this is a small, conservative group, they won’t consider that. This is a Waterfall project, all the way.”

Stacy said, “Don’t get hung up on terms. Organize your project tasks into one to two week segments. When planning the next task to focus on, negotiate with the other managers to dedicate the staff you need for that one to two weeks. After that task is completed, re-negotiate and plan the next one.”

“You’ll want to have more than one possible ‘next-task’, that way you can select the task based on the resources available for that sprint period.”

Bob added, “Have a Before Sprint Planning, and outline exactly what requirements will be met during the sprint. Add an After Sprint Lessons Learned, and you can better plan for the next ones.”

Susan replied, “I’ve already used a Work Breakdown Structure to define the tasks and resources. Organizing dedicated sprints would not be difficult. And, the management team will understand the need to have focused resources for each sprint, as long as they can protect the other priorities as well.”

Susan added, “Still, it sounds like I’d be sneaking a little Agile into their organization.”

Grabbing her camera bag and getting ready to leave, Stacy said, “Don’t get hung up on the terms, think of the tools in the toolbox, and using the ones you need to protect the project and your client’s investment in it. That’s the most important thing.”

Productivity

The Power of the Checklist

June 20, 2017June 20, 2017
by tom lamm

It sounds old fashioned, even quaint, the Checklist or To-Do List. As a personal time management tool, it is often equated with the idea of tying a string around your finger. I disagree; do not underestimate the power of the checklist.

Many years ago, as a programmer, I worked in a shop that had a complicated procedure to copy program code from the developer’s desktop to the first-tier testing environment. It was a common for somebody to miss a step and create havoc for all of the programmers and testing staff. At about the same time, watching a documentary about the Apollo Space missions, I learned that NASA uses checklists “for everything”. I created a checklist for that complicated procedure, and never made a mistake with it again. Another developer on the team saw me using my checklist, and snickered in a friendly way, poking fun at my “crutch”. Later that day he had some code to copy, made a mistake, and came back asking for a copy of that checklist.

Years later, learning to be a private pilot, I learned that pilots, both private and commercial, have many checklists. Unlike a car, you cannot pull the plane over to the side and take care of something you forgot. Pilots rely heavily on checklists for everything from safety checks before take-off to the landing procedure.

These days, like everybody else, I have a sophisticated computer dedicated to time management and communication in my pocket, my smartphone. I keep a both long and short term checklists of “TO DO” items. Imagine going into the weekend with that list of things you need to get done, and knowing that you won’t forget any of them. You might not get to everything, but any item you skip will be one you decided to skip, not something you forgot.

In IT, there are procedures that must be followed when a server goes down. Even if the backup server takes over automatically, there are checks to perform to ensure that the backup is working properly and people to notify about the problem. That list of “must do immediately” items should be available where all of the necessary staff can access it. By the way, storing it on the server is really not a good idea.

In any office environment, who do you call if the VOIP phones are out? Who do you notify if the office needs to close unexpectedly? Something as simple as a checklist can make the difference between a moment of crisis and a difficult situation that you are well prepared for.

Now I need to open my checklist app and tick off “Create Post About Checklists”.

Uncategorized

Be Proactive About Risk

June 18, 2017June 18, 2017
by tom lamm

Stacy set down her camera bag and joined Jim and Bob at the table, “I just heard a very thoughtful quote from Admiral Ernest King. He said, ‘The mark of a great ship handler is never getting in a situation that requires great ship handling skills’. That started me thinking about projects and risk management.”

Jim replied, “I used to think that risk management meant knowing when to have the team work over-time and scheduling a weekend. That Admiral is talking about avoiding the need. So, how do you two avoid the issues before you have to solve them?”

Stacy answered, “When they talked about the Admiral’s quote, one example they discussed was to call a tug to bring the ship into port instead of doing it yourself. It seems like more effort and time, but it is much lower risk. So, I’d say that one answer is knowing when to get expert help.”

Susan joined in the conversation, “I like to look ahead at the project and try to spot the weak points. Tasks assigned to a ‘light’ resource, maybe somebody with less experience. Or inherently difficult tasks, or possible bottle necks in the critical path.”

Bob chimed in, “Or resource availability, whether human resource or material. If you need something for a task, and it’s not available, you end up with a work crew that is just standing around.”

Jim asks, “So what do you do about that?”

Susan replied, “When I plan ahead and spot a potential risk, I like to have one or two backup plans thought through and ready. If the risk is serious, I’ll even put the contingency right into the project plan documents. That way, I’m not trying to solve a problem at the time it occurs. Often, because I’ve thought it through, I see the risk becoming a reality, and can go to the backup plan before it is a realized problem.”

“Sure,” said Bob, “for instance, I’d rather have a crew assigned to doing something else if I really suspect that some material will be a day or two late. That’s a lot better than realizing that the material will be late when the crew shows up. It takes more planning up front, and sometimes planning for things that never happen, but prevents a lot of wasted time.”

Jim jumped in, “But, when it does hit the fan, you already have a plan in place. Sounds, like you try to put your plan into action even before it hits the fan.”

Stacy finished her lunch saying, “That’s what works for me, knowing when to have a contingency, just in case. Knowing when to get an expert, thinking through the ‘what-ifs’.”

As they were getting ready to leave, Jim wrapped up, “Sounds like a pretty smart Admiral there.”

Overheard at the Project Management Cafe

Waterfall vs Agile, in a Nutshell

June 11, 2017June 19, 2017
by tom lamm

Overheard at the Project Management Café.

Jim sets down his cup and says, “I’ve been hearing a lot about Agile, so, what is the difference between Agile and Waterfall? In fact, what the heck is Waterfall?”

Stacy puts down her sandwich, “The black-and-white answer is this: With the Waterfall style, you plan the project upfront, each milestone, each task, and have the entire plan in front of you. With Agile you plan the project, but you approach it with the attitude that change is inevitable, useful, and welcome.”

Bob replies, “Agile accepts the fact that you cannot plan everything up front, so you need to deal with challenges as they come.”

Jim, “Sounds like simple old fashioned project management to me. ‘Don’t get too set in your ways, stuff happens’”.

Bob, “That attitude works well no matter what methodology. Agile has other aspects, the teams are more self-managed. They have regular ‘retrospective’ meetings during the project to ask ‘What went wrong’, instead of a single one at the end. There’s more, but the main difference is really in attitude. With waterfall the team directed by one manager. Agile teams are self-directed, the manager is more of a resource than an authority.”

Jim, “So, which is better? Which is the one to use?”

Bob, “Hey, Stacy, you’ve been an amateur photographer for a while now, you probably have a bit of gear by now. Which is the right lens to use?”

Stacy, “Well, it depends. If I’m taking nature photos I pack one or two, but for people I prefer…”

Jim, “Hey, I see your point, there is no right lens to use.”

Stacy, “Sure, Agile, Waterfall, a bit of a blend, it all depends on the circumstances that the project manager finds ‘on the ground’”.

Bob, “When I have a very inexperienced team, or a new offshore team that we have not built a rapport with, I am more directive, I end up using more of a Waterfall approach. If the team is highly experienced and used Agile before, you know ‘Not their first rodeo’, I use a heavy Agile approach. For that team, I can do less managing, mainly be the resource that clears roadblocks and run interference for them. That lets me focus more on my other projects and teams.”

Stacy adds, “Actually, there are more nuances than just that. There are varieties and mixtures of both. Different versions of Agile. Different ways to implement Waterfall, even hybrids of both.”

Jim finished his cup, “Ok, so it really is a case of choosing the best options, based on the team, the project, and what the PM and team work with best.”