Tasks and Time

Tasks are always associated with time... Tasks are started at some point in time and they are completed at some point in time.  We're almost always interested in the duration (how long it takes) from the Start Time to the Completion Time.

Start Time and Completion Time are the biggies, but there are a few more timestamps that we're often interested in capturing (especially when tasks are performed by humans).  Here's my list:

• Assignment Time - the point in time when the task is assigned to a person (or group).  In most of the process applications I've implemented we don't assign a task to a person until that task is ready to start... but sometimes we do know who should work on a task long before the task should start. If we relate this in terms of an appointment on your calendar, this would be the time when you made the appointment.

• Scheduled/Estimated Start Time - the point in time when the human should (ideally) start working on the task.  In many process applications we don't predict when a task should start - it simply starts when the process flow reaches the task.  Explicitly scheduling or estimating start times can be very useful if you need to determine whether or not a specific process is "on track" to complete on time.
• Ready To Start Time - the point in time when everything is ready for work to begin on the task.  
• Start Time (aka Actual Start Time) - the point in time when the human starts working the task. It's our fondest hope that the Scheduled Start Time, Start Time and Ready To Start Time are all the same - but when dealing with humans they seldom are.

• Scheduled/Estimated Completion Time - the point in time when the task should be completed.  This is really an expression of "how long the task should take".  In most cases I've seen this set by adding the expected duration of the task to the Start Time - but there are cases where a hard and fast completion time is critical if you need to know whether or not the process can complete on time.
• Completion Time (aka Actual Completion Time) - the point in time when the human completes the task.

There are also some optional timestamps we need from time to time that you may encounter:

• Reassignment Time - It happens... and there can be multiple of these for a single task instance.
• Task Cancelled Time - Often good to know - not every task gets executed to completion.
• Task Escalated Time - This might possibly be redundant, since reassignment and cancellation are very common elements of task escalation.
• Task Suspended Time - Sometimes things come up and work on a task just has to stop. As with reassignment, this can happen multiple times per task.
• Task Resumed Time - If a task was suspended, you will almost certainly want to know how long it was suspended.

Analysis of all of these timestamps can help you figure out whether or not your process is running smoothly.  For example, whenever the actual Start Time is later than the Scheduled/Estimated Start Time you may have a problem... but to determine where the problems lies you'll need to take a look at the Ready To Start Time.  Was the human slow in starting the work, or was there a delay that prevented the human from starting the work?

In all honesty, I've never worked with a client who captured all of these timestamps for every task... and I am certainly not advocating that you should complicate your solutions by capturing this information unless you really need to.  Just don't be surprised in those rare instances that you encounter a process analyst who needs this level of detail.

If you've encountered requirements for capturing additional task oriented timestamps (or you have better descriptions/names for these timestamps), I'd love to hear about them.

Task Escalation

Adam Deane has a nice post on Escalation Management over on his blog which sums up as follows:

Escalations are the bread and butter of every BPM solution....
  ....I’ve never heard of escalation management being a mandatory component of a BPMS. I’ve never seen an escalation best practice. It seems everyone just takes it for granted. 

I have to agree with Adam on this one... escalation of tasks is taken for granted - right up until you have to implement it.

Case in point is a recent discussion with one of my colleagues (paraphrased here):

 A client approached us with the following problem:
- The process has a due date.
- Activities have due dates relative to the process' due date (e.g. one activity must be finished 20 days before the due date of the process)
- If the due date for an activity is missed, an event should be raised and acted upon.

After discussing this with colleagues, we came up with two approaches:

1. BMPN-based solution:
• Add a timer to  each activity, configure them to trigger after due date.
• Create another activity to handle the missed deadline and attach it to the activity.
2. Programmatic Solution:
• Create a Service that is triggered once an hour.
• Fetch all instances of the process and for each instance check the active task's Due Date. If it is passed, act on it.

Alternative 1 is a "pure modeling" alternative, that might attract some people. Though you need to do add the timer to each activity which has a deadline.
Alternative 2 means more work initially to implement the timer triggered service, but with careful design I guess it could be used for all activities. 

I suppose you could characterize this (with apologies to William Shakespeare) as:

"To Model... or not to Model?  That is the question!"

It's a good question:
Is "Escalation of a Task" an aspect of your solution that should be modeled, or is it an aspect of your solution that is better expressed in some other way (perhaps with code)?

Escalation of a task often seems to be better expressed as a policy rather than as a process.  In many cases it seems to be more difficult to determine whether or not a task requires escalation (perhaps it is overdue) than it is to carry out the actual escalation logic (send an email to the manager).

Of course there is no "right" or "wrong" answer... It simply depends on the specifics of your problem... but I think there are some guidelines that can be helpful in determining what to do.

First answer these questions:

1. Are the conditions that determine that a task "needs escalation" common across the process or specific to the task?
2. Are the actions that must be performed when a task "needs escalation" common across the process or specific to the task?

If the answers to both of these questions are "common across the process", then I don't think it's appropriate to model the escalation behavior on your process diagram.  Your escalation logic and behavior is a policy that is applied to the process - more so than an aspect of the specific tasks.

Common logic and behaviors (let's call them policies) that are applied across your process are generally best captured as such... That will make it much easier to review and update them when the need arises.

Digressing slightly - You should also think ahead in terms of how you'd support changing this policy at runtime.  A centralized expression of the escalation policy is probably going to be easier to modify than distributed logic... and it's probably a sure bet that the Business Folks are going to want to tweak these policies over time.

If the answers to either of the questions above are "specific to the task", then you need to think about it a bit more.  If escalation of a task requires more than notifications and reassignment of the task (if alternate activities must be performed and the flow of the process is altered) then you most likely should model those activities on your process diagram (perhaps hidden in a nested process to keep your diagram clean ).

I'm not sure if the advice in this posting will meet Adam's desire for "Escalation Best Practices"... but hopefully it will keep the conversation going and help us (BPM Practitioners) reach consensus.

The Business Process Application Building Checklist

Your team's process for building a Business Process Application is going to be involved and nuanced, but let's start off with a check list for how to get started implementing any process application:

1. Assemble the core of your BPM Dream Team who will build the process application
2. Identify a "significant" subset of the chosen process that can realistically be built in about 90 days (longer than 90 days and your odds of failing rise dramatically)
3. Create an  Executable Business Process Diagram so that you can step through all the paths of the process with your business owners
4. Create a Functional User Interface for each Activity to insure that each task is fully understood by you and the business owners
5. Define the key Process Performance Reports (PPRs) to insure you understand what's important to the business owners, and add Tracking Points to the BPD to capture the data the PPRs will require
6. Identify all the remaining Human Interfaces to the Process that will be required to support the process 
7. Refine the Process Data Model based on the requirements that you've discovered thus far.

This checklist might seem simplistic... but it's critical to "be sure" to check off all these aspects before you start building anything else.

Update: This checklist has grown a bit since originally published based on some excellent feedback

Process Performance Reports

When working with new-to-BPM clients I often have to help them differentiate between traditional Business Performance Reports and Process Performance Reports.

A Business Performance Report generally answers questions something like the following:

• How many units of X did the Y group process last month?
• How does the X processing rate of the Y group compare to last years processing rate?

A Process Performance Report generally answers questions something like the following:

• How long (on average) did it take Y group members to process an X?
• Why did it take longer for the Y group to process an X in these instances?

Everybody knows how to gather the data that they need for their Business Performance Reports... and once they give it some thought most folks can also grasp how to gather the data for their Process Performance Reports.  They just need a little nudge to change their thinking from "how many" to "how long".

Process Performance is all about "How long did it take?".  If you want to know "How long?" then you have to know when "it" started and when "it" finished. 

If they don't give it much thought, when asked where to capture time stamps in their process your typical business owner is likely to say:

"Track Everywhere!"

That's not necessarily a bad thing - but you need to remind your business owner that the purpose of tracking is to gather timing and business data that their Process Performance reports are going to require.

Before you start tracking anywhere, you really need to identify all of the Process Performance reports that the business needs.  Defining these reports is clearly the responsibility of the business owner, but you may have to give them a little help.  My suggestion is to focus on what questions each report is meant to answer, rather than on what the report is going to look like (bar charts, pie charts, etc.)  There are many ways to present data - at this point you have to be focused on getting the data in the first place.

Here are some questions that might be asked about the rather generic Request Resolution process you can see later on this page:

• How much time do we spend reviewing requests that are eventually declined?
• Do some reviewers take significantly longer to decline a request than others?

The next step towards gathering the data that they will need for each report is to get the business to identity the start and end points for the intervals that each report represents.

Most BPM suites can automatically give you the durations of all activities... but often your report is interested in durations that are measured across multiple activities or whose start and end points are dependent on the path the process takes... as is the case with the questions I just posed.

If it's not obvious where in your process you need to capture a time stamp, then a good place for you to start is to identify the major phases of your process.  For example, many processes have a Preparation, Decision Making, and Implementation phase.  If you track the transitions between these phases, then you will probably have most of the time stamps that your reports will need.

Another good place to start it to identify all of the significant milestones and events in your process.  Often these points correspond to the phases of your process, but there may be other points that are "exception points" in the process, like the withdrawal of a request.

In the following diagram, you'll see that I have added "Tracking Points" where the process flow crosses the phase boundaries and at some significant "exceptions":

This Business Process Diagram (BPD) is from IBM's WebSphere Lombardi Edition - and utilizes the Intermediate Tracking Event to indicate the specific points where I want to capture a time stamp.  Other BPM suites may use other mechanisms, but the point is - I need to know when the process flow passes any of those points.

Once I have identified all the points in my process where I want to capture a snapshot, I need to figure out what business data I need to associate with each tracking point... and that can sometimes be tricky.

If you ask your typical business owner what to track, they will most likely say:

"Track Everything!"

This is an understandable reaction - "Something" may be important, and if you don't track it you can't evaluate its effect on the process.
Unfortunately, it's just not practical to "Track Everything!"  Your tracking data base will quickly become huge, and there will be loads of superfluous and redundant data.

So how do we narrow down what business data to track?

Start with the bare minimum - What do the Process Performance reports need?
At a minimum, we have to track the business data that is required to answer the questions that our reports are meant to answer.   If we have a report that needs the business data, then we track the business data - If not we don't.

Take a look at the process diagram on this page, and let's assume that we want to build a report that answers the question: "How much time do we spend reviewing requests that are eventually declined?"

We've got the time stamps for this report - Start Review is the beginning and Declined is the end.  With the time stamps of those two points we can answer our question.

Now let's ask a different question: "Do some reviewers take significantly longer to decline a request than others?"

This report relies on the same tracking points, but now we have to capture the identity of the reviewer.  Note that we only have to capture the reviewer's identity at Declined to prepare this report.

I am sure you can think of a host of other questions, such as "Is there something about the request itself that complicates the decision to decline the request?"

Perhaps there are a few elements of the business data that could help answer this question, but we may have just crossed the line from data that we should track to data that belongs in the company's system of record.

Data about the request that does not change over the course of the process usually doesn't need to be tracked.  New records are added to your tracking data store every time your process passes a tracking point.  If you also have a business data store - that holds the "current" details of the request, then nothing is gained by also storing that information with all of your tracking points.

We're pretty much done at this point.  We've identified all of the points in the process where we need to capture a time stamp, and we've identified all of the business data that we need to store along with those time stamps.  The only thing left to do is to take one more look at all of the Process Performance reports that the business identified and make sure that nothing was missed.

The process that I've outlined for defining where and what to track is admittedly subjective but it's also pretty easy for a good Business Analyst to follow.

Starting with a Process Diagram and a list of Process Performance Reports, the Business Analyst can (and should) define their Perspective of the Process Data  (where to track data and what data to track).

With the Analyst's Perspective of the process data defined, we're one step closer to finishing our process application, and one step closer to giving our business folks a great return on their BPM investment... and that ought to make everyone happy.

BPM Implementation Dream Team

The last few months have been really fun for me.  I've had a couple of really successful BPM implementation engagements and seem to be on a roll.  I would love to take credit for the success of these clients, but the reality is that the makeup of their implementation teams is what really made the difference...

What makes a great BPM Implementation Team?  Of course it's the character of the people on the team - but it's also the "perspectives" of those people that really makes the difference.

In the bad old days of software development, one group would write requirements and another group would implement those requirements.  Let's call the first group "Business" and the second group "IT".
There never really was a 'Business/IT Team" that was tasked with building the solution... it was a Customer/Supplier relationship.

Rapid Iteration BPM implementation projects, like the ones that I work on, depend on "Business" to take on building responsibilities and "IT" to take on requirement writing responsibilities.  We don't structure responsibilities like this just to make everyone feel good, we structure things this way because of the way things are:

• All Business requirements have Technical implications
• All Technical implementations have Business implications

When the business folks hit the technical hurdles, and the technical folks hit the business challenges, there's great incentive to find "another way" that gets the team to the solution sooner.  Shared misery builds strong bonds.

The core of our ideal BPM implementation team are two individuals; the Business Lead and the Technical Lead.

In some ways the relationship between these two folks resembles Agile's Pair Programming.  That's the practice of sitting two developers down side-by-side at a single workstation.  While one developer types in code, the other developer reviews the code to catch errors and insure compliance with the requirements... take that concept up to the level of Business Relevancy and you have one person who is concentrating on getting the technical aspects of the solution built and another who is concentrating on getting the business aspects of the solution built.

While we're touching on the topic of Agile programming, I want to hasten to say that many of the concepts of Agile are applicable to a BPM project, but there are some very key differences in the priorities that you assign to the implementation of features and functions.

In BPM, the Process is the Story.  The User Stories for individual process activities, although interesting, are just chapters in the book.  You must give priority to implementing all of the chapters to some minimal level of functionality before working on any other aspects of the solution.  The process-wide dependencies (activities, flow, payload) must be the focus of your initial Sprints, or you are quite likely running in the wrong direction.

But I digress... back to the core of our dream team...

The Business Lead is responsible for getting all of the required business functionality of the process implemented.  It should also be noted that the Business Lead owns the interpretation of the business requirements.  Any ambiguity in the business requirements must be clarified by the Business Lead.  Any changes to the business requirements must go through the Business Lead.  The Business Lead is the fountainhead of all things business (as far as the team is concerned).

The Business Lead is the primary interface between the implementation team and a host of business folks.  The business cast includes the following:

• Process Owners - usually the Operations folks who are responsible for keeping the business running smoothly
• Business Subject Matter Experts - the folks who really know the details about specific aspects of the business
• Process Participants - the folks who are going to use the solution that you're building

The Technical Lead is responsible for getting all of the required technical functionality of the process implemented.  As with the Business Lead, the Technical Lead owns these aspects of the process, but very likely there are many specialists involved to do the actual implementation.  What you are looking for is someone who has very good rapport with the Business Lead and the technical background to spot all of the technical implications of the process that must be addressed.  As I have blogged before, BPM solutions don't usually require a lot of Software Engineering, so the breadth of the Technical Lead's knowledge is usually much more important than the depth of the Technical Lead's knowledge... You need someone who knows which experts are necessary and when to engage them.

The Technical Lead will be supported by a host of developers, and often these folks are specialists.  You'll often find the following cast:

• Process Flow and Data Developer - someone who really groks how to implement the process and data requirements with your BPM suite.
• Human Interface Developer - someone who is a wizard at building all the Human Interfaces to your process.
• Integration Expert - someone very skilled in utilizing external systems... Mostly SQL and Web Service skills
• External System Expert - you'll need one per system that you need to interface with

So here's a diagram of your extended dream team:

Note that the involvement of the team members varies in intensity over the life of the implementation project.  The Business and Technical Leads are always "on call", but the lion's share of the Business Lead's efforts are early in the project, and the lion's share of the Technical Lead's efforts are in "the middle" of the project.  When you get to User Acceptance Testing the efforts of the Leads seem to be evenly split.  All of the other team members can come and go as needed... continuity is provided by the Leads, so the supporting cast members can be utilized effectively on multiple projects if need be.

If you organize your team around a Business Lead and a Technical Lead as I've described, then I'm willing to bet that your project will run smoother and you'll reach your goal sooner - and I'm also willing to bet that you'll enjoy getting there.

Tips for the Business Process Developer - Human Interfaces to Business Processes

I've probably mentioned before that there's anecdotal "evidence" that when implementing a Managed Business Process folks will spend about 80% of their time building the human interfaces to the process.  That sounds like a very bad thing, but in reality it's just a testament to how good the BPM Suites are at building the Process Choreography and Orchestration pieces.

Given that building your human interfaces is going to consume a big chunk of your development effort, it's helpful to step back and consider just what sorts of human interfaces a business process needs.

Task Notification Interfaces
Folks can't be expected to complete their tasks unless they know that they have tasks that they need to complete.

In many cases you will want to send email to a participant to notify them that they have work to do.  That's actually a very good approach when you have a participant who only does work for you infrequently.  Checking email is something that folks do all the time, so an email notification that there's work to do will probably get noticed.
Email notification isn't a good approach if the participant frequently has lots of tasks to do.  Their email inbox will quickly become overloaded, and they'll have difficulty keeping track of the work that they are supposed to do.

For participants who frequently have a lot of tasks to perform, you'll want to build some flavor of a "To Do List" interface.

"To Do List" interfaces have three goals:

• Make sure the participant knows what tasks they are responsible for
• Make sure the participant knows when each task is due
• Help the participant prioritize which task to work on next

That last bullet is (of course) the hard one to implement.  A specific task may be very important to the completion of a specific process - But that specific process may be far less important than another specific process.  Often times the participant will need to consult Process Status information (see below) in order to determine which task they really ought to work on next.

Task Completion Interfaces
Folks can't complete their tasks unless you provide them with interfaces that let them do their work.

I've blogged a lot over the years about implementing Human Powered Services - probably because I've met a lot of folks who haven't thought enough about how to effectively build them.  I'll ask you to Google for my past blogs on the subject and just warn you that you can waste a heck of a lot of time on these interfaces if you don't concentrate on providing only the functionality that's absolutely required.

Process Status Interfaces
It's good to know the state of a process - Knowing what tasks have been accomplished and what tasks are left to be performed can be very helpful information.

Improved process visibility is one of the key promises of BPM, so think these screens through very carefully.  If you don't do them well, then you probably won't meet your BPM objective.

You will often build Process Status Interfaces for the folks that "own" some operational aspect of the process.
For example, if a supervisor is responsible for the completion of specific processes, then that supervisor will want a "dashboard" that presents the current status of all the running processes.  The supervisor will be particularly interested in any processes that are "at risk" - those processes that may not complete "on time".

When you build a process status interface, you will almost always incorporate functionality that will allow the user to "do something" to influence the running processes.  For example, if the user can see that a specific process is "at risk", they may need to initiate an escalation process or reassign some of the tasks to other participants.

Process Status Interfaces have the following purpose:

• Display the current status of the running processes that are of interest to the user.
• Clearly identify any processes that are "at risk"
• Provide interfaces for the user to intercede in any process that is "at risk"

Optionally, a process status interface may also provide a estimates on when specific process instances may be completed.  These estimates are based on the remaining tasks that must be performed and estimates for how long each task is expected to take.  For more accurate estimates, historical information about the past performance of the process can be used.

Participant Workload Interfaces

Participant workoad interfaces are closely related to the process status interfaces that I've just described... but they focus on the workload for each participant rather than on the status of specific running processes.

If you are a manager who is responsible for assigning work, then it's very important for you to know what everyone is already working on.  An interface that shows the user "who is working on what" is very important when new work must be assigned, or when uncompleted work has to be reassigned.

In a sense, these workload screens are a roll-up of the Task Notification "To Do List" interfaces I mentioned earlier, but they're meant for the supervisors rather than the workers.

Process History Interfaces
Being able to review the history of a process is key if you want to know whether or not the process has been running smoothly.

As mentioned before, improved process visibility is a key goal of BPM, and visibility into how well (or how poorly) instances of the process ran in the past is crucial.  Without this information you can't really hope to improve the process in the future.

Process history interfaces are essentially reports - and it's should come as no surprise that you may need to produce many reports for each type of process.  These reports are usually cumulative - What were the average execution times for the process?  Once norms have been established, then seek out the "unusual" process runs and try to figure out why those instances were outside the norm.

Given the nature of reporting, count on generating a lot of process history interfaces for a lot of audiences.  It's really hard to anticipate all of the reports the business may want, but start with the most obvious and insure that you're capturing all the data that's necessary to generate those reports.

If you're stumped on what "the most obvious reports" are for a process, then start by considering what you need to "remember" from the Process Status and Participant Workload interfaces that I described.  If a supervisor ever has to intercede in a specific process - by reassigning tasks or initiating an escalation procedure - then you probably need to remember "why" they needed to intercede.  As the saying goes, "Those who forget the past are doomed to repeat it".

Business Process Interface Snippets
Perhaps I've left out some aspect of Human Interface that your Business Process will need - but I think you will find that most of the interfaces that you need will fall into one of the categories that I've described.  Thoughtfully consider the interface functionality that you really need, and I think that you will find it a lot easier to build out your user interfaces.

My final offering is this: Don't confuse the human interfaces that I have described with specific screens.
Many of the human interface aspects that I have described will routinely be combined together on a single screen, or you will find a need to incorporate an aspect of a Business Process on an existing screen.

Consider building out each "aspect" of your Business Process Interface as a "snippet" or "panel", and you'll find it much easier to tailor your interfaces for each of the audiences that you need to serve.

Tips for the Business Process Developer - Building a Task Focused User Interface

When you start implementing a managed business process, your first focus is probably on the definition of the process itself - What activities need to be performed to complete the process?

Once you've defined the activities, then your focus will probably turn to the information that the process deals with - What information is needed to perform each activity, and what information is gathered or transformed by each activity?

Assuming that you've gotten this far, your focus will now probably turn to building the user interfaces for the activities in the process that will be performed by people - the human tasks.

Over the years, my colleagues (from IBM and Lombardi) and I have evolved a process for building Task Focused User Interfaces that we've found to be quite successful.  It's a simple process that may seem like common sense to many, but it's worthwhile to follow this process.  It will help you focus on addressing the right things first - and help you to get your managed business process deployed as quickly as possible.

Here's a "Discovery Map" diagram of our process for implementing Task Focused UIs:

A typical business process contains many human activities - that's very important to keep in mind at all times.  You have to build a functional task UI for every human activity in the process before you're done.  If you get tunnel vision and focus in on making a single human task as "perfect" as it can be, then you'll delay the initial roll-out of your solution.

With this in mind, you'll see the logic of the process that we've adopted:

1. Build "Just Enough" human interface to give you the ability to "step through" this activity and all of the paths of your process
2. Define "Just Enough" of your interfaces to underlying integrations to give your integration developers the information that they need to start building the "real" integrations
3. Get a fully functional task UI working as soon as your "real" integrations are ready
4. After everything is functional, then (and only then) work on making the task UI "pretty"

On that last point (step 4) - remember that "everything functional" goes beyond a specific human task - All the human tasks should be functional before you worry about making any of them pretty.

The real driving point (and the factor that makes this process successful) is constantly building "just enough" to let the other members of your implementation team start working on their tasks.  You won't be able to step through all of the paths of the process until you have "just enough" UI to do so.  Your integration developers won't be able to start until they know the interfaces that your tasks will require.  Your functional testers can't sign off on the process until all of the tasks in the process are functional.

Common sense... but often we lose our senses in the heat of battle, so it's best to have a process definition to fall back on.

---

Here are some closely related postings for those of you who may want to delve deeper:

• Building an "Executable BPD"
• Understanding Activity Data
• Building Functional Task UIs

Functional Task UIs: Instructions, Context Information, Data Capture

When implementing a BPM solution, your first objective is to make sure that you get the Right Tasks to the Right Participants at the Right Time.  That's often easier said than done, but let's assume that we've accomplished that goal...

Now we need to start worrying about how to enable the participants to actually complete their tasks.

When a participant opens up a task, assuming that the task is meant for a human rather than a machine, we need to provide them with a user interface for completing their task and interacting with our BPM system. Implementing these UIs often consumes most of your development effort - I've had clients tell me that they spend 80% of their time on the UIs for the tasks in their process applications.  That sounds horrible, but when you dig a little deeper you'll usually find that projects as a whole are taking a lot less time than they did before - but it's still worthwhile to try to reduce the time is spent building task UIs.

 A functional task UI contains 3 categories of elements:

1. Instructions for performing the task
2. Context Information that is needed to perform the task
3. Data Capture controls for information that must be gathered

I find it very helpful to create "starter" screens for my tasks that break out each of the above categories into separate sections - folks always always dive right into developing polished UIs and skip this step, but they really shouldn't.  Build a "starter" screen as I suggest and you'll identify all the integrations that you'll need - and avoid a lot of headaches later.

Instructions:
What is the user supposed to do?
Instructions "should" be easy... but you'd be surprised.  Even after process analysis some folks are confused what a specific task really needs to do.

Many of the user interface designers that I know hate the idea of putting instructions on their screens.  Designers strive for the "Self Evident" interface where the users just intuitively know what it is that they're supposed to do when presented with a screen.  That's a fantastic goal - but I encourage you to write those instructions down even if your end goal is to build an instruction-less screen.  Even if the end user never sees those instructions, it will help all of the interested parties grasp exactly what the task is that the end user needs to accomplish... it will help you validate the requirements for the screen itself.

Note that the Instructions that we seek are those that help the user accomplish a task, not instructions on how to use a screen. I've blogged elsewhere on the advantages of User Manual Driven Development, which focuses on "how to use" - but don't fall into that trap for your Task UIs.  Focus on "What must be done" rather than on "How to use".

Context Information:
What information that is specific to the task does the user need?

This is where you'll discover all the "Read" integrations that you will need.  You can't display context information unless it's been passed to you, or you can "Read" it from somewhere.  It may take weeks to actually implement those integrations, but once you define the interface to the integration you can create a placeholder and keep on going.

Data to Capture:
What information does the screen need to gather from the user to perform the task?

This is where you'll discover all the "Write" or "Update" integrations that you will need.  The information that you capture on the screen needs to "go somewhere"... and that means you'll either pass it along or "Write" it somewhere.  As with the "Read" integrations, it may take time to build the "real thing", but you've got enough to define the interface to the integration and keep on going.


A Functional UI is way better than an Unfinished UI:
If the UI  for your task has Instructions, Context Information, and can Capture the required data, then you really ought to move on to something else.  It may not be pretty, but it's functional, and you can't deploy your solution until you have a functional UI for every task (so go work on the next one).