Project Suicide

This was sort of a funny scene in a project meeting. 

One person describing the challenges at one point, spontaneously and dramatically motions to take a knife and slit both wrists.

This absolutely got people's attention.

Understanding the struggles the person was expressing, and trying to add a little lightheartedness to the situation, I say:

"This is a tough project, pass around the knife."

This got a good hearty laugh around the table, with one person saying that this was the quote of the day. 

Anyway, we want to make operations as effortless as possible on people, but the project work to get there is definitely making people work for it. 

Let's avoid project or people suicide--be supportive of each other, pace ourselves, team together, and problem-solve to get it successfully over the finish line.

Soon we can celebrate all the challenges we overcame together and from our determined efforts, all the wonderful results. ;-)

(Source Photo: Andy Blumenthal)

Project Suicide

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)

Birthing An IT System

Agile Doesn't Mean Endless

So Agile development is great for iteratively working closely with customers to develop and refine information systems that are useful to them and the organization.

But even in Agile, there is a beginning and an end to the sprint planning and project management.

Taking Agile to somehow mean endless in terms of adding more and more requirements or scope creep is not what is intended. 

Agile has to be bound by common sense somewhere between what is needed for a minimally viable product (MVP) and what is achievable with the designated resources, objective, and scope. 

Good project managers always have to be sound arbiters and be willing to ask the tough questions and determine if something is truly a requirement or simply a wish list item that is out of scope (but of course, could perhaps make it in for future enhancements).

We need to understand the difference between genuine customer service and irrational project exuberance. 

It's not a dangerous project bubble we want to create that can and will get busted, but rather a successful project that is delivered for our customers that help them do their jobs better, faster, and cheaper.  ;-)

(Source Photo: Andy Blumenthal)

Agile Doesn't Mean Endless

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. ;-)

Flowchart Your Programming

Do-It-Yourself (DIY) Application Development and Enterprise Architecture

The Wall Street Journal, 24 September 2007 reports that “new [DIY] tools let businesspeople avoid the IT department and create their own computer applications…and no knowledge of computer code is required.”

How does this benefit users?

• “Users say they are saving time and money by creating their own applications”
• They “are able to build exactly what they want, without having to explain what their looking for to someone else.”
• “Others like being able to wite programs that would have been too minor or personalized to bother the IT department with.”
• “Adjusting DIY programs…can also be simpler than asking the IT department for program tweaks or updates.”

What are the downsides?

• “There is some risk in the lack of a track recod for such companies [offering these DIY services], and in the possibility that a provider will fail, leaving its customers without access to the applications they developed online.”
• “Some businesspeople may underestimate the effort required to write their own programs.”

Strangely enough, the article leaves out some of the biggest gaps with DIY application development, such as:

• Approval by the organization’s IT governance to ensure that the ‘right’ projects are authorized, prioritized, funded and monitored for cost, schedule, and performance.
• Compliance with an organization’s enterprise architecture to ensure such things as: business alignment, application interoperability and non-redundancy, technology standardization, information sharing, and strategic alignment to the target architecture and transition plan.
• Assuring IT security of applications systems, including confidentiality, integrity, availability, and privacy.
• Following a defined, repeatable, and measurable structured systems development life cycle (SDLC) approach to application development.

The WSJ article actually compares DIY application development to when businesspeople learned to create their own PowerPoints presentation rather than having to run to the graphics departments to build these for them.

While there may be a place for DIY application development for small user apps (similar to creating their own databases and presentations), from a User-centric EA perspective, we must be careful not to hurt the enterprise, in our efforts to empower the end-users. A balanced and thoughful approach is called for to meet user requirements (cost effectively and quickly), but at the same time protect enterprise assets, meet strategic goals, and assure overall governance of IT investments.

Do-It-Yourself (DIY) Application Development and Enterprise Architecture