Our Design Process: Harnessed Creativity

The newly formed architecture team (Caitlin, Jin, and I) are beginning to formalize our process for generating and supporting innovation in system design. At KR, design is intended to be a creative process. Our reputation holds that we are an organization that excels in producing innovative approaches to complex, enterprise-scale problems. Some projects do not require and, in fact, cannot support innovations in design or methodology. As an organization, we have learned (and are continuing to learn) this lesson the hard way. In these cases, the process detailed below may be inappropriate. Still, our ideal client and project allow us to:

1. flex our creative muscles,
   
2. bring 100's of years of implementation experience to bear,
   
3. and utilize processes that we know will result in solid solutions while supporting our organizational needs.
   

So, our basic design flow is represented in this picture:

The steps are:

1. Problem immersion
   
2. Immersion sharing
   
3. Approach forming
   
4. Gestation
   
5. Insight incorporation
   
6. Vetting
   
7. Documentation
   
8. Socialization
   
9. Implementation approach
   
10. Guidance
    
11. Formal follow-up
    
12. Learning
    
13. Sharing
    

Much of my understanding of the creative process comes from the research of Albert Shapiro. Here is a relevant excerpt from his 1985 article, "Managing Creative Professionals".

Organizational Citizenship Behaviors (OCBs)

"Organizational Citizenship Behaviors (OCBs) are a special type of work behavior that are defined as individual behaviors that are beneficial to the organization and are discretionary, not directly or explicitly recognized by the formal reward system. These behaviors are rather a matter of personal choice, such that their omission are not generally understood as punishable. OCBs are thought to have an important impact on the effectiveness and efficiency of work teams and organizations, therefore contributing to the overall productivity of the organization." – Wikipedia entry

OCB behaviors are part of why KR is special. Beyond expertise, these professional courtesies that we share with each other and our clients make a real difference to the organization. Academic studies on OCB (see the work of Dennis Organ) ties their expression strongly to the experience of job satisfaction. Employees satisfied in their jobs voluntarily contribute in ways that transcend the strict definitional boundaries of their job specifications. These behaviors matter. We need to celebrate them. We must strive to resolve job dissatisfaction and inspire OCB.

Type of organizational citizenship behaviors:

1. Altruism (Helping): Is selfless concern for the welfare of others. Helps others who have been absent, or helps others who have very work-loads.
   
2. Courtesy: Take steps to try to prevent problems with other workers. Does not abuse the rights of others.
   
3. Civic Virtue: Attends meetings that are not mandatory, but considered important. Keeps abreast of changes in the organization.
   
4. Conscientiousness: Does not take extra breaks. Obeys company rules and regulations even when no one is watching.
   
5. Sportsmanship: Does not consume a lot of time complaining about trivial matters. Always focuses on what's right, rather than what's wrong.
   

How do your behaviors map to these five? Is dissatisfaction with your current role or environment blocking you from contributing? Have you taken time to praise OCB behaviors in your coworkers?

PRPC Access Control: OperatorIDs, Access Groups, and Roles

The OperatorID (an instance of Data-Admin-Operator-ID) is the starting place. Here you may assign a single Access Group (an instance of Data-Admin-Operator-AccessGroup) to provide the access control profile for the user.

The Access Group has 3 distinct mechanisms for conveying access rights:

1. RuleSet or Application – grants access to individual RuleSets and/or RuleSets contained in an Application
2. Work Pools – grants access to Work tasks contained within a specific Class Group
3. Roles – define rights to both instances and rules at a class level

The Role itself is just a predefined tag (Rule-Access-Role-Name). Alone, it does not convey or deny access. The Role to Object records ((Rule-Access-Role-Obj) contain linkages between a Role and a specific class. To make managing these linkages simpler, PRPC 5.x has a Security Wizard than can be accessed by selecting Tools->Security->Role Names and double-clicking a particular role to manage.

The wizard allows you to identify any number of class to associate with the Role. The security system is, by default, exclusive. PRPC will not grant access unless explicitly provided. The Role to Obj linkages allow you to specify:

• Open, Modify, Delete, and Browse on Instances of a class and
• Open, Modify, Delete, and Execute on Rules contained by a class.

The numeric values assigned are 0-5 and correspond to the "Production Level" setting from the System record.

The production level values can be:

To convey access, the number shown in the Role to Obj linkage must be greater than or equal to (>=) the current system's Production Level. Incidentally, the Production Level can be found on the clipboard at pxProcess.pxAdminSystem.pyProductionLevel.

10 Guiding Principles for Surviving Complex Projects

Knowledge Rules excels at the implementation of complex projects. We embrace a style which allows us to make, communicate, and capitalize on progress. The key to survive and thrive is to turn complexity into simplicity in your mind and the minds of the team. Embrace a zone of calm and simplicity without ignoring hard work. Here are a few guiding principles about how to do just that:

Imperfect knowledge:

1. Focus on knowing enough to start (or step) rather than enough to finish. learn to operate with imperfect and incomplete information.
   
2. 15-minutes each day. Chaos is the natural state. Every day inject 15-minutes of order. Gray areas outnumber both the black and the white; chip-away every day.
   

Reduce the mental scope:

1. Decompose and ignore. Use the big picture to chunk-up the problem. Then chunk-up the chunks again.
   
2. Consider the 'Happy path' first. Shoot for the center of mass. Target 80% of the value and deliver 100% satisfaction. Don't wallow in the complexity of exceptions.
   

Taking steps:

1. A step in wrong direction is better than no steps in the perfect direction. Progress is more valued than perfection.
   
2. Build to show, show to inspire, inspire to build.
   

Decriminalizing change:

1. Embrace creative destruction. Learning quickly is better than planning perfectly.
   
2. Fail fast, cheap. Take risks, but take them quickly. Indecision consumes more than action, failure, and recovery.
   

Getting done:

1. Done is better than perfect. Emphasize function over perfection.
   
2. Rinse, repeat: find your iterative groove to improve.
   

I will add detail to each step in following postings.

Art of Posting Answers

There is an art and science to answering a question properly. The best answers address both questions that were asked and those that should have been. In answering questions in a community space, it is important to consider that you are providing guidance not only to the current questioner, but to all those who will have similar questions in the future. You will earn your reputation among generations unhired if you can follow good form in responding to today's questions. Here are some of the key concepts to keep in mind when responding to technical questions:

• A concise summary of what elements of the question are relevant to the problem– what did you consider in determining the response?
  
• A detailed description of the approach to the problem– what thinking went into your response?
  
• A detailed diagnosis of the ISSUE with the originally intended solution—why is the approach failing?
  
• A detailed description of how you would addressed the solution technically – what is your approach to the solution?
  
• A detailed list of what other things to try in debugging the problem further—what would you have done before asking the question?
  

It is fair game to ask additional questions. In doing so, provide some rationale for those questions. Engage the person with the problem to help solve their own quandary and arm the next generation with a list of questions that they should address for their own questions.

Provide enough detail so that the response will stand on it's own, but also refer to key sources for background information. Helping the community find their own answers is more important than answering specific questions. Use links, search terms, or other keyword references to PRPC online help, PDN, KR SharePoint, Pegatricks.com, or Google.

Happy answering.

Art of Posting Questions

There is an art and science to posing a question properly. Good questions encourage good answers. Following proper form in asking questions often results in self-resolution. It is a process that makes a difference. Here are some of the key concepts to keep in mind when asking a technical question:

• A concise description of the business and technical background – why are you trying to do what you are trying to do?
  
• A detailed description of the solution space– what are you trying to accomplish?
  
• A detailed description of how you have addressed the solution technically – what is your approach to the solution?
  
• A detailed description of the ISSUE with your intended solution—how do you know there is a problem?
  
• A detailed list of what you have tried and what you have not tried to resolve the ISSUE—what have you done about the problem and what were the results?
  

I find that most technical questions seek assistance to fix problems with an attempted work-around rather than to solve the original quandary. That is the nature of the problem solving path, we ask once we have reached the end of our ropes. Take the time to back-up and start from square one: don't ask me about the end of your rope ask me about the start. Many times the first approach was the appropriate approach and a minor tweak results in success.

For some questions, you may not know how to address the solution space at all. But, to borrow from Ben Franklin, KR helps those who help themselves. These questions are welcome, but you must explore help sources such as the PRPC online help, PDN, KR SharePoint, or Pegatricks.com for hints prior to posting. Part of engaging answerers is satisfying the community that you are:

• interested in solving the problem on your own, not passing-off hard work,
  
• capable of understanding and acting on a response,
  
• respectful of the communities time.
  

Happy asking.

Voicemail: Keep It Crisp

Phone conversations should either be a) completely social or b) have a point. When my phone rings, I make this assumption. If I can answer, I do. If I cannot, I will assume that if you have a point that you will leave a voicemail. If it is an important point, you will leave a voicemail AND follow-up with a brief email. Why follow-up? Voicemail communications isn't perfectly reliable. Cellphones make this even more true.

There is an art to leaving a voicemail. Do not treat my recording as a proxy for me. Long voicemail is terrible. Normal format is appropriate:

1. Greeting – Be polite, but brief.
   
2. Name -- Clearly and slowly. No matter how well you think you know me, you have to do this.
   
3. Short Point of Call –Do be pointed. Two sentences or maybe three if they are short.
   
4. Call to Action
   
5. Contact Number slowly
   
6. Contact Number slowly AGAIN