The Next Big Thing
Posts about next generation technologies and their effect on business.

Looking at technology projects in trouble (firefighting 101)

helping others.pngAfter a week of Tech Con, I need to get back in the saddle and start blogging so I thought I'd start with one issue I’ve given some thought to recently. It is tackling reviews of projects that are currently underway and in trouble. Governance may help you determine where to focus but once you find those projects in need, the real work begins.

 

Sometimes good technologists are brought into existing projects that are in trouble -- it is just a fact of life. A good technologist has experience that should be applicable to almost any technical situation and should have the skills to advise others on solving problems.

 

Unfortunately, when you are overcome by events, it can be difficult to follow your own advice. Over the years, I’ve pulled together a few generic questions and activities that can be pulled out and used to validate that you have not overlooked the obvious.

 

Like all consultants, when you are trying to orient yourself to the situation, you ask a number of questions. Asking the team rather than just diving in and looking at the situation from their view always provides some good perpectives. A few of the questions I use with project leaders and architects are:

  1. Describe any resource constraints that remain for the project.
  2. Share any contractual issues or pending changes for this project.
  3. Describe any significant differences between the “as designed” model and the project as it is being implemented.
  4. What are the greatest business risks to this project be completed as planned? Do you feel the impact is adequately documented and approved?
  5. Describe any client relationship issues outstanding with this project.
  6. When was the last joint user/project team meeting discussing the status of this project? What was the user’s level of satisfaction expressed in the meeting?
  7. Who is the design authority or architect of the solution that is ensuring the project is technically being built as designed?
  8. What is the most significant technical risk remaining on the project?
  9. What is the project’s turnaround plan and what is your confidence level that the dates will be met?
  10. Is there anything you know that could help ensure success?

Some of these should be documented in the project work products, but many times it is the discrepancies that are the most interesting.

 

There are also common areas of investigation such as:

  • Vulnerabilities to events outside the organization’s control such as denial-of-service attacks – a safety check to see how proactive the team is at identifying vulnerabilities. Business continuity comes into play here as well.
  • Troubled, dependent projects, unsupported vendor software, and key people inclined to leave the organization

What areas have I left out?

The supply and demand issues of governance

IT Economy.pngLately, I’ve been in discussions with people working in the architecture and software development space about increasing their delivery quality and capability. Various organizations have different problems, but this team is fairly mature and they have defined a great deal of process and project work products.

 

For me governing development efforts has a number of parallels with managing an economy. In economics, you can control an economy from the supply side or the demand side. Some organizations spend a great deal on the supply side making sure work products and processes are defined, creating a great deal of documentation. They may have process owners even, who are focused on ensuring that the processes is up-to-date. In this case, there was no shortage of supply.

 

Teams may overlook the need to focus on the demand side. How should these work products be used by the leadership in making better decisions? Do the leaders understand their value and how to use them? Are they actually being used? How can we prove it? … If we get the leaders to actually use the materials (increasing demand), the work products will get created more consistently, the process followed and the whole effort will generate greater value. It is about leadership, not about creating more stuff.

 

That is one area were Agile techniques have greater focus. Agile approaches are zealous about ensuring work output is understood and used. Unfortunately, they may give up a level of consistent delivery in the process.

 

Understanding your organizations supply of process work products and how they are actually used can go a long way to increasing performance.

What's this thing called DevOps?

During a conversation last week with a Forrester senior analyst (Dave West) from the UK, I learned about a new term and a new industry "movement" - DevOps.  He said that there has been recent interest in this topic which combines, both literally and figuratively, the terms "developer" and "operations".  So of course when our call ended, I did some searching on the term and learned that there is indeed a fledgling "DevOps" community of developers and sysadmins who have recognized - as many of us - that applications should get built with full knowledge of the operational environment in which they will run. This group of primarily UK/Northern European IT professionals has collaborated on recommendations to remove some of the silos between those who build and those who run applications. This represents a cultural change as much as a need for integrated teams and processes. Two years ago in this space I spoke of the need for developers to use ITIL practices "to understand the real impact of new applications on the run-time environment and how they need to be designed differently for the complex, distributed environments we have today".  Perhaps not much has really changed, but at least the conversation has broadened.


The DevOps community sees agile and lean teams better suited to collaborate and drive DevOps thinking because of their matrixed approach, but I don't see why two-way communication, which is both the bridge needed and the current barrier, should be limited to small teams. We need to see push and pull of information equally from both developers and operations.  Silos within the IT organization or even when traditional outsourcing and multi-vendor partners are engaged are challenges but not insurmountable. 


Just as one example, when developing a web application I really do need to understand the capacity (network, servers, storage, database) of the current run-time environment as well as the security levels, and I need to work with both sysadmins and service management personnel to have them understand the service level, security and run-time requirements, work out conflicts, and also engage them as necessary for integration and other testing. EDS had the right idea with an initiative called Designed for RunTM that has continued to evolve towards what I believe the DevOps folks envisage, but there is still work to be done.


I do really agree with the recommendations of the DevOps gang that a multi-disciplinary approach must be taken between developers, testers, change and release management, and operations engineering groups such as system administrators and those who manage system capacity and availability. They suggest that team members might gain expertise across the divide.  Understanding the best practices from both CMMI and ITIL would help, as well as having the IT skills and experience to go along with them.  I've studied this "CMMI & ITIL" process integration area fairly deeply and have spoken at several conferences on the need for integrated application development, service management and infrastructure engineering processes. Drop me a line if you would like to discuss further or pick up a presentation. 

What Do Organization Structures Really Look Like?

Traditional organization charts typically depict the management hierarchy and maybe some committees and dotted line reporting relationships.  This is inadequate for today's organizations.  Today there are many more roles and relationships by which business actually gets done.  In general, we don't know what our business organization structures really look like.


I reported in August on a new specification proposed in response to the Organization Structure Metamodel RFP (Request for Proposals) issued by the OMG (Object Management Group).  The RFP seeks proposals for an organization structure modeling language.  This new proposal challenges traditional ways of representing organization structures.  Organization models typically focus on the management hierarchy of "business units" with annotations of some exceptions.  The new specification recognizes that these divisions, departments, groups, teams, etc., represent only one general type of relationship in an enterprise.  The following are additional types of relationships that should be considered.



  • Matrixed product development teams

  • Committees, task forces, work groups

  • Project teams, strategic initiative teams

  • Participants in business processes or choreographies

  • Business partner relationships, liaisons, contracts

  • Ad hoc collaborative relationships

  • Exchanges of materials, work products, business transactions


Each enterprise should consider the types of relationships of interest in an organization model and the amount of update activity this will require to keep the model current.


Each of these relationships has people involved in specific roles.  The relationships and the roles outline how work actually gets done.  Some of these relationships are relatively stable, and some are quite dynamic.  Most of them are not new, but have not been viewed as aspects of an organizational structure.  In a recent BP Trends article, "The Process Managed Org Chart: The End of Management and the Rise of Bioteams," Peter Fingar describes some radically different organizational structures that may involve additional types of relationships.


In the past it was necessary to make announcements or draw diagrams on paper and distribute copies in order to provide this information.  Today this information can be maintained by computer to be readily available to everyone who has a need to know.  We shouldn't need to keep track of who is doing what in our heads or send out email queries to find out from people we think may be informed.  Computers can manage the complexity of a model with many types of relationships, they can perform timely update and distribution of this information, and they can provide the selective display of information to meet particular needs.  A more robust model will provide better definition of responsibilities, and provide a more complete representation of the organization for planning, coordination and business transformation.


A modern enterprise should have an on-line, real-time organization model that is updated as the organization changes and reflects the relationships by which work is getting done.  Some updates may be accomplished by manual input as relationships are established.  Most updates should come from the systems that support these relationships such as business process management systems, project management systems and contract management systems.  This real-time model will not only provide information for people, but should support the operation of systems for reporting, exercise of control and coordination of activities.  Capture of this information in an integrated model will reduce administrative overhead and ensure consistency among different systems.  In addition, such an organization model may retain historical information on roles and relationships to help identify people with insights or experience from past relationships.


Enterprises need this information now.  It will become increasingly important as organizations continually change to meet new business challenges and establish relationships outside the traditional management hierarchy with shared services, outsourcing and virtual enterprises.

Amateur Social Engineers

In a previous blog, I addressed the need for Security Awareness Training to recognize and avert social engineering attacks.


A recent event in the U.S. demonstrates a blatant and amateur attempt at social engineering.  This case involves an independent and conservative investigative report, or depending on your perspective, an activist, James O'Keefe and three other associates.  O'Keefe is known for successfully infiltrating political organizations like ACORN, posing in various undercover roles to expose information, wrongdoings, and the like, using classic social engineering tactics.


The latest event involving the district office of U.S. Senator Mary Landrieu of Louisiana has been widely covered in the media, including articles CNN and FoxNews, and many others.  A brief quotation from the article at CNN illustrates the social engineering tactics that were used:


The two men were "each dressed in blue denim pants, a blue work shirt, a light green fluorescent vest, a tool belt and a construction-style hard hat when they entered the Hale Boggs Federal Building," the release noted.


After they entered the building, the two men told a staffer in Landrieu's office they were telephone repairmen, according to the release and Rayes' affidavit. They asked for -- and were granted -- access to the reception desk's phone system.


O'Keefe, who had been waiting in the office before the pair arrived, recorded their actions with a cell phone, said the affidavit by Rayes.


Flanagan and Basel later requested access to a telephone closet, claiming they needed to perform work on the main phone system, the release and affidavit stated.


According to Rayes' affidavit, the two men went to a U.S. General Services Administration office on another floor and requested access to the main phone system. A GSA employee then asked for their credentials, and the two men said they left them in their vehicle, the affidavit said.


Whatever the aims of O'Keefe and his associates, they are currently being charged with entering (a federal) office under "false pretenses for the purpose of committing a felony."


However, this story sounds like it might have come straight from Kevin Mitnick's book "The Art of Deception".  The one difference is that these men appear to be amateurs in the field of social engineering.  Why?   They got caught.  And, to me, the reason seems to be that they did not "do their homework" to prepare for unforeseen circumstances (i.e. being asked to show credentials).


The lesson to be learned from this (for those in IT and security) is that the senator's office appears to have done an adequate job in training its staff and employees with proper procedures and security awareness to spot and avert social engineering attacks.  The staff involved did not fall blindly for the ruse posed by the workmen's overalls and hardhats that appeared to make them look like telephone service personnel.  Rather, they were sent to the proper office (General Services Administration) and once there, they were asked to show proper credentials. 


The result?  BUSTED !!!


Even if the two men posing as telephone repairmen had obtained false credentials, I would hope that the GSA employee would have checked to insure that "maintenance had been scheduled", or called their telephone service providers to verify the employment and activities of the two men. 


And to borrow the subtitle of Kevin Mitnick's book again, that is how you "Control the Human Element of Security". 

Search
Showing results for 
Search instead for 
Do you mean 
Follow Us
Featured
About the Author(s)
  • Steve Simske is an HP Fellow and Director in the Printing and Content Delivery Lab in Hewlett-Packard Labs, and is the Director and Chief Technologist for the HP Labs Security Printing and Imaging program.
Labels
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.