Kanban Visual Task Boards

Just wanted to share this best practice for Kanban or Visual Task Boards

This is a way to layout work/workflow and track and communicate progress. 

Previously, many professionals use colored sticky notes on a wall or whiteboard.

Today, tools like ServiceNow have the capability built right in. 

This was an example that I created in just a few minutes. 

Visualize your team’s work and focus on what needs to get done, who the tasks are assigned to, the status, and keep driving continuous improvement in the workflow and project. 

Color coding can be used for different tasks and you can see the legend at the top.  

Tasks can be easily dragged and dropped from one column (status) to another. 

Create transparency and collaboration on your projects–try Kanban Visual Task Boards. 😉

(Source Graphic: Andy Blumenthal)

DMAIC Reengineering

A colleague gave a wonderful talk the other day on process engineering.

The key steps to reduce waste (Lean) or variation/defects (Six Sigma) are as follows:

Define – Scope the project.

Measure – Benchmark current processes.

Analyze – Develop to-be processes (with a prioritized list of improvements) and plan for implementation.

Improve – Executive process improvements.

Control – Monitor/refine new processes.

It was amazing to me how similar to enterprise architecture this is in terms of: defining your “current” and “future” states and creating a transition plan and executing it.

Also, really liked the Project Scoping questions:

– What problem do you want to solve/what process do you want to improve?

– Why do you need this?

– What is the benefit?  And to whom?

– What are your objectives for this effort?

– Who are the key stakeholders?

– When is this needed and why?

I think process improvement/engineering methodologies like this can be a huge benefit to our organizations, especially where the tagline is “Why should we change–we’ve always done it this way!” 😉

(Source Photo: Andy Blumenthal)

>Information Sharing Standards and Enterprise Architecture

>

In response to the 9/11 Commission’s recommendations, the Intelligence Reform and Terrorism Prevention Act (IRTPA) of 2004 called for an Information Sharing Environment (ISE), “an approach that facilitates the sharing of terrorism information” and that requires the President to designate a Program Manager for the ISE and to establish an Information Sharing Council to advise the President and the Program Manager.

The Common Terrorism Information Sharing Standards (CTISS) Program Manual is a construct for ISE. It defines both functional standards and technical standards.

• Functional standards—According to the CTISS Program Manual, these are “detailed mission descriptions, data and metadata on focused areas that use ISE business processes and information flows to share information.” From an enterprise architecture perspective, I believe this would correspond to the business and information perspectives of the architecture as well as be extended probably to the performance perspective. In other words, functional standards correlate to the three business perspectives of the Federal Enterprise Architecture. These are the standards that define our requirements, in other words, how we measure performance (for example, Balanced Scorecard), how we engineer business processes (for example, Lean Six Sigma), and how we describe information sharing requirements (for example, NIEM or U-CORE, and Information Exchange Package Descriptions).
• Technical Standards—“methods and techniques to implement information sharing capability…[for] acquiring, accessing, producing, retaining, protecting, and sharing.” From an enterprise architecture perspective, I believe this would correspond to the services, technology, and security perspectives of the architecture. These correlate to the three technical perspectives of the architecture. The technical standards include how systems will interoperate or share information (for example, J2EE, .NET), what technology standards will be employed (for example, XML, SOAP, UDDI) and how security will be assured (for example, various from NIST/FIPS, ISO, IEEE, and so on).

What I like about the CTISS is that it attempts to define a comprehensive framework for the ISE from the highest-level being the domains of information (such as intelligence, law enforcement, homeland security, foreign affairs, and defense) and drills down to the security domains (SBU, Secret, and US-SCI), reference models, (FEA, DoDAF, IC EA…), standard types (metadata, data, exchange, and service), standards bodies (NIEM, W3C, OASIS…), and then the standards themselves.

As an initial impression, I think next steps are to articulate how I share information with you or you share with me. Currently, we are still defining techniques for future sharing of data, like developing metadata, creating a data dictionary and schema, defining exchange standards, and service standards to discover data through registries. It like responding to someone who asks, how do I get to your house, by saying, we need to pave roads, design and manufacture cars or buses, install traffic signs and lights, and so on. That’s all infrastructure that needs to be built. That still doesn’t tell me how I get to your house. While we are making huge progress with information sharing, we’re still at the early stages of figuring out what the infrastructure elements are to share. But it seems to be a running start!

>Lean Six Sigma and Enterprise Architecture

>

Enterprise architecture is one way for an organization to drive business process improvement and technology enablement. Another way is through Lean Six Sigma.

Federal Computer Week, 3 March 2008, reports that “DoD rallies around Lean Six Sigma: The methodology has become the Defense Department’s ‘tool of choice’ for business transformation.”

“Lean Six Sigma is simply a process-improvement method for reducing variability and eliminating waste.” With Six Sigma (developed by Motorola), the idea is to make processes efficient and repeatable, so that there are fewer than 3.4 defects per 1 million. The Lean (developed by Toyota) concept refers to “eliminating any steps that don’t add value.”

In Lean Six Sigma, process improvement is enabled through the following steps:

1. Define—identify problem and measures
2. Measure—capture data points
3. Analyze—discover areas for process improvement
4. Improve—implement process changes
5. Control—verify and validate that improvement is attained and sustained

In 2000, Deputy Defense Secretary Gordon England made Lean Six Sigma the foundation for DoD’s continuous process improvement program.

Currently, “about two-thirds of DoD organizations by some estimates are committed to Lean Six Sigma.”

DoD is training their people in Lean Six Sigma and intends to have 5% of its employees attain Green Belt (involves typically a week of training) and 1% reach Black Belt (typically involves approximately two years of training in math and statistics and several years experience working on projects as Green Belts).

However, DoD has been criticized by some for focusing more on the training, than on translating that training into practical on the job know-how to transform the Department.

Yet, by some measures DoD has made improvement. The Army claims to have “completed 770 Lean Six Sigma projects, from which it estimated savings of $1.2 billion in 2007.”

To me it seems like enterprise architects would do well to work in partnership with Lean Six Sigma professionals in order to understand the business processes, improve them, and identify requirements to technology enable those. In User-centric Enterprise Architecture, business drives technology rather than doing technology for technology’s sake. Lean Six Sigma can help business led the way for truly useable and usable technology solutions.