Project Governance and Gate Reviews

Thought this may be helpful for those looking at a Governance Process and Gate Reviews for project management. 


This aligns the Capital Planning and Investment Controls (CPIC) process of select, control, and evaluate phases with the Systems Development Life Cycle (SDLC). 


There are 5 notional gate reviews with associated documentation for project conception, initiation, planning, execution, and launch.


Of course, this can be modified as needed based on the project threshold and governance stringency required and seeks to create strategic alignment with the goals of the organization. 


(Credit Graphic: Andy Blumenthal)

Birthing An IT System

Managing IT projects is no easy task.


You’ve got to get the requirements right. 


Technical issues need to be resolved. 


Dependencies have to be lined up. 


Integrations need to work. 


Design should be user-friendly and intuitive. 


Change management takes real leadership. 


And so much more. 


A lot needs to go right for the project to be a success. 


While of course, just one or two bad apples in the project equation can quickly make for a failure if not controlled for. 


But you can’t let it…the show must go on, progress is waiting to be made, and the systems need to be delivered for the benefit of the organization. 


This is where real strength and determination by so many good people come in. 


Keep moving things forward–one step at a time–don’t stop!!!—another step and another–heave ho, heave, ho–until one day soon a beautiful and efficient IT system is born. 😉

(Source Photo: Andy Blumenthal)

Who You Calling Ugly Baby?

So in multiple organizations, I have heard systems referred to as ugly babies!


Whether or not it’s true, it certainly doesn’t make the IT folks that develop, run, and support that system feel very good. 


Are some of these (legacy) systems ugly?


Well, of course, they are. 


Many of them work despite themselves. 


What I mean by that is they are awkward to navigate and use. 


The functionality is flawed or outdated.


The workflows are unnecessarily complex.


The user interface is inconsistent and sloppy. 


The user experience is punishing. 


I told someone recently in using a particular system that was so convoluted:

“Is this system what they give to prisoners and make them use over and over again to punish them for hideous violent crimes?”


Seriously, that’s how it felt, even as I knew it was still lightyears ahead of what a paper process still used in other organizations looks like.


Generally better than the waterfall methodology for the systems development life cycle, I understand that one dilemma with agile development is that requirements can be spotty from sprint to sprint and instead of doing the hard work and thinking it out upfront, users are made to expect a nearly endless series of enhancements and tinkering, which isn’t practical functionally or financially either.


Even an ugly baby is still ours, and we love it and nurture it, and even help it change for the better–that’s part of our responsibility. 


Whether we parented a real baby or an IT system, we have pride of ownership and a sense of accountability to the person, system, and future. 


My father always taught me never to throw out dirty water until you have clean water. 


Similarly, we shouldn’t throw out the (ugly) baby with the bathwater. 


We need to work together–technologists and system users–to make truly functional systems and a user experience more like gaming where the players are so happy, attached (and even addicted) to it that they sometimes don’t even get up to eat or go to the bathroom. 


We should love what we have and use, and we should, therefore, work hard to make these things great.


And an ugly baby can be made gorgeous again. 😉


(Source Photo: Andy Blumenthal)

People, Process, and Technology Lifecycles

Lifecycles.jpeg

The table describes the alignment of the various people, process, and technology lifecycles commonly used in Information Technology to the CIO Support Services Framework (CSSF).


The CIO Support Services Framework describes the six key functional roles of the Office of Chief Information Officer (OCIO)–it includes:


1) Enterprise Architecture (Architect)

2) Capital Planning and Investment Control (Invest)

3) Project Management Office (Execute)

4) CyberSecurity (Secure)

5) Business Performance Management (Measure)

6) IT Service (and Customer Relationship) Management (Service)


All these OCIO Functions align to the lifecycles for process improvement (Process), project management (People), and systems development (Technology).


– The Deming Life Cycle describes the steps of total quality management and continuous process improvement (Kaizen) in the organization.


– The Project Management Life Cycle describes the phases of managing (IT) projects.


– The Systems Development Life Cycle describes the stages for developing, operating and maintaining application systems.


Note: I aligned cybersecurity primarily with doing processes, executing projects, and designing/developing/implementing systems.  However, cybersecurity really runs through all phases of the lifecycles!


My hope is that this alignment of people, process, and technology life cycles with the roles/functions of the OCIO will help bridge the disciplines and make it easier for people to understand the underlying commonalities between them and how to leverage the phases of each with the others, so that we get more success for our organizations! 😉


(Source Graphic: Andy Blumenthal)

Requirements Management 101

Requirements Management.jpeg.JPG

This was a funny Dilbert on Requirements Management. 


In IT, we all know that getting requirements can be like pulling teeth. 


No one either has time or desire to provide them or perhaps they simply don’t know what they’re really after.


Knowing what you want is a lot harder than just telling someone to automate what I got because it isn’t working for me anymore!


In the comic, Dilbert shows the frustration and tension between technology providers and customers in trying to figure out what the new software should do. 


Technology Person: “Tell me what you want to accomplish.”


Business Customer: “Tell me what the software can do.”


In the end, the customer in exasperation just asks the IT person “Can you design [the software] to tell you my requirements?”


And hence, the age old dilemma of the chicken and egg–which came first with technology, the requirements or the capability–and can’t you just provide it!


(Source Comic: Dilbert By Scott Adams)

What Is The Creative Process and Success?

Creative Process

One of my colleagues at work had this hanging on his wall. 


It caught my eye and I thought it was worth sharing.


The creative process (ah, not my style of working, however–I am too much of a planner and worrier): 


1) Work Begins – It starts with, “I have a bright idea” or a “go do” from some other genius. 


2) F*ck Off – Then comes some procrastination and maybe thought process about what you are going to do, but in the meantime, everyone leave me alone to percolate and brew. 


3) Panic – Of sh*t, time is running out, and where the h*ck am I on this project, better get my a*s in gear. 


4) All the work while crying – Hurry, hurry, hurry and get it done. Wa, I feel like such a crybaby and wreck, but I’m going to finish it, I am. 


5) Deadline – Made it by a hair…uh, the whole thing was easy, for me, as pie!


Another thing that I heard this week is that “success is failing to fail.”  


Think about that a minute.  😉


(Source Photo: here with attribution to Toothpaste for Dinner)

Versioning Gone Wild

Version Out Of Control

So software versioning is supposed to be a way to manage change control. 


However, many vendors have gone out of control with versioning. 


1) Incompatibility–It isn’t backward compatible, so if you try to work with an older version file/data, you may be sh*t of out of luck getting it to work. 


2) Alphabet-Numerical Soup–We have so many versions of the same/similar thing, we can make your head spin with buyer envy. 


3) Functionally Indistinct–Version changes are so minute or insignificant that there is virtually no difference to the end-user, but you’ll love it anyway. 


4) Long And Meaningless–Some versions just seem to go on and on into the weeds…like version 2.10.3.97–ah, let’s compare that to the new version of the week of 2.10.3.98, and don’t forget the 2.10.4 will be a completely different platform, so you better remember to order the right one. 


5) Upgrade Pathless–You want to be on the current version, well your version is so legacy and ancient, there’s no (easy) upgrade path–you have to install 26 patches, hot fixes, and 9 new versions and then you’ll be on the right one!


6) Maintaining Multiple Versions–You’ll need to maintain multiple versions of the same product, because your data on the older version can’t be migrated to the new one. Can anyone say multiple maintenance fees?


7) Out Of Support–Your older version that you spent a lot of money on is no longer current  and is now out of support–so scr*w you unless you pay us again for the next money maker version. 


If you want to kill your brand and possibly your customers’ sanity, keep on going mindless version crazy. 😉


(Source Graphic: Andy Blumenthal)

Requirements, I Don’t Know

Requirements Management

This was a funny cartoon. 


Who are we?  


Clients!


What do we want?


We don’t know!


When do we want it?


Now!


This is like way to many IT projects…


The customer knows they need to do something, because of changing market conditions, internal (dys)functioning, arising competition, or external mandates and regulations. 


But when the IT project managers and business analysts interview and ask the customer what they want and need to address these…quite often they get blank faces and hands raised in circuitous, endless doubt. 


What do the customers really want?


For IT to define, solve, and make their problems go away–and by the way do it yesterday and without any extra / proportionate resources


For some IT “professionals” that may be a little lacking themselves, you end up getting half-assed solutions to half-baked requirements that accomplish nothing or perhaps even break things more.


Hence, the true miracle of technology–to read minds and deliver valuable solutions to problems that no one could fully define to begin with! 😉


(Source Cartoon: Roz Blumenthal @ Facebook)

A Different Definition For IV&V

A Different Definition For IV&V

In IT circles, IV&V generally refers to Independent Verification and Validation, but for CIOs another important definition for leading is Independent Views and Voices.

Please read my new article on this: here at Government Technology — hope you enjoy it.

Andy

(Source Photo: here with attribution to Joi)

Flowchart Your Programming

Flowcharts have been used for quite some time for visualizing and organizing business processes and making them more efficient (e.g. business process reengineering).

Now flowcharts are being used to build and link reusable programming code.

NoFlo or Flow-Based Programming (FBP) simplifies application development by using libraries of pre-written code and then dragging and dropping them into your process flows.

This leverages objected-oriented programming (OOP) and uses modules of open-source code, which are linked together to create a full program that solves a business problem.

The flowchart helps to avoid spaghetti code by providing for a more organized, modular, object-based development environment.

These flowcharts can not only be a collaborative tool where developers can build or map code, but can also be part of the systems documentation that ensures a higher-level of understanding of the total programming solution.

NoFlo raised over $100K on Kickstarter in 45 days in order to advance this project from Javascript to iOS, Android, and Python platforms as well.

To me, this programming paradigm seems to have real legs:
– A process-based model for decomposing solutions
– Simple information visualization through a common flowcharting toolset, and
– Reusable object code from programming libraries in the cloud.

I’d say YesFLo–this makes a lot of programming sense. 😉